This group is locked. No changes can be made to the group while it is locked.
Date
1 - 4 of 4
[OpenDaylight Discuss] Virtuailization addition and affinity service
|
Benny Rochwerger <BennyR@...>
Anees,
toggle quoted message
Show quoted text
I have to disagree with you on the need for the Affinity Service to touch the network. Yes, we do not need yet another virtualization implementation, but this is not about virtualization is about abstraction. As you may recall in the original Defense4All proposal we talked about the need to have controller services that provide an abstraction of the network and give higher level applications (L4-7, Security) the capability of monitoring and controlling the network without needing to fully understand the L2-3 topology. These is what at the time we called the "Traffic Redirection" and "Statistics Collection" services. After presenting our requirements, we were told that these type of network abstraction services is exactly with Affinity is all about and after a few discussions with the Affinity team we agreed that with some minor changes (mainly syntactic) we can rely on Affinity to do the low level network control for us (the slide set that describes these changes is attached). The need for a network abstraction is orthogonal to network virtualization, our application for example works both in physical networks and in virtualized networks (in fact all the deployed PoCs we have up to now are physical), so it will be wrong in my opinion to look at something like affinity only in the context of virtual networks. Having said that, I do believe that when virtual network are deployed, affinity (or similar) should leverage the network virtualization service, i.e., in that case instead of touching the network directly it should ask the network virtulization to do it. Benny -----Original Message-----
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Anees A Shaikh Sent: Saturday, November 23, 2013 5:05 PM To: discuss@... Cc: <affinity-dev@...>; ovsdb-dev@...; opendove-dev@...; <vtn-dev@...> Subject: [OpenDaylight Discuss] Virtuailization addition and affinity service Unfortunately, I couldn't attend the last TSC call where the issue of conflicting services in the virtualization edition was discussed further. But in reading Dave's notes, it seems there was some expectation that the current approach would need to be revisited: "big piece of post-release work to do on finding the proper abstractions under which all three projects can complement each other", referring to VTN/OpenDOVE/Affinity. While we may need a way to support multiple virtualization implementations simultaneously, this problem applies to the current VTN/OpenDOVE/OVSDB projects and not the affinity project in my view. Affinity metadata service should never conflict with any of these implementations, because it provides a database of user-specified affinities / policies, not an additional virtualization implementation -- i.e., it should not touch the network (unless its scope is changing significantly). If folks from these projects, have a different view, let's discuss it further. thanks. -- Anees _______________________________________________ Discuss mailing list Discuss@... https://lists.opendaylight.org/mailman/listinfo/discuss |
|
Anees A Shaikh <aashaikh@...>
Benny, your last sentence is what I am getting at -- so I don't think
there is any disagreement. I'm not arguing that we don't need network abstractions separate from network virtualization. And I agree that affinity and other services could apply beyond the virtualization edition. But in the context of the virtualization edition, we have implementations managing the network. Affinity and other such services should be providing information about user intent to these implementations -- not providing their own manipulation of the network, which we've seen interferes with what the network virtualization services are trying to do. thanks. -- Anees Benny Rochwerger <BennyR@...> wrote on 11/25/2013 02:46:42 AM: From: Benny Rochwerger <BennyR@...>service further. But in reading Dave's notes, it seems there was some expectationfurther.
|
|
Benny Rochwerger <BennyR@...>
Anees,
In that case I remove my disagreement, however from our point of view it is the affinity service that is providing the abstraction and the enforcement, whether affinity touches the network directly or thru a network virtualization layer should transparent applications the network abstraction API (I.e. affinity in our case) Benny Anees A Shaikh <aashaikh@...> wrote: Benny, your last sentence is what I am getting at -- so I don't think there is any disagreement. I'm not arguing that we don't need network abstractions separate from network virtualization. And I agree that affinity and other services could apply beyond the virtualization edition. But in the context of the virtualization edition, we have implementations managing the network. Affinity and other such services should be providing information about user intent to these implementations -- not providing their own manipulation of the network, which we've seen interferes with what the network virtualization services are trying to do. thanks. -- Anees Benny Rochwerger <BennyR@...> wrote on 11/25/2013 02:46:42 AM: From: Benny Rochwerger <BennyR@...>service further. But in reading Dave's notes, it seems there was some expectationfurther.
|
|
Suchi Raman <suchi.raman@...>
Anees and Benny, No disagreements with earlier discussions. Affinity abstraction is a high level API that specifies the network path requirements (policy, connectivity, ...) for a set of endpoints. Endpoints may correspond to an application or represent some traffic. The affinity implementation will not assume openflow on the southbound side.
As for enforcement -- who enforces what and when -- we will use notifications from affinity manager, so that VTN/Dove may reprogram their networks when configuration changes.
VTN is openflow-based and offers filtering and redirection services natively within each "virtual network" (slice), so the data path for these affinities -- path redirect and access control affinities -- for a VTN-managed network is a direct translation. Translation with Dove may be more involved. I think programming a mixed network (VTN + dove) has other challenges as well that may need to be resolved centrally, but as you say let's table this for later.
Suchi On Mon, Nov 25, 2013 at 3:02 PM, Benny Rochwerger <BennyR@...> wrote: Anees, |