This group is locked. No changes can be made to the group while it is locked.
Re: [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.
From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of Anees A Shaikh
Sent: Saturday, November 23, 2013 5:05 PM
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.
Discuss mailing list