Re: [OpenDaylight Discuss] Virtuailization addition and affinity service

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. 


On Mon, Nov 25, 2013 at 3:02 PM, Benny Rochwerger <BennyR@...> wrote:

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)


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.


-- Anees

Benny Rochwerger <BennyR@...> wrote on 11/25/2013 02:46:42 AM:

> From: Benny Rochwerger <BennyR@...>
> To: Anees A Shaikh/Watson/IBM@IBMUS,
> "discuss@..." <discuss@...>,
> Cc: "<affinity-dev@...>" <affinity-
> dev@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "opendove-
> dev@..." <opendove-dev@...>,
> "<vtn-dev@...>" <vtn-dev@...>
> Date: 11/25/2013 02:47 AM
> Subject: RE: [OpenDaylight Discuss] Virtuailization addition and
> affinity service
> Anees,
> 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
> Unfortunately, I couldn't attend the last TSC call where the issue
> of conflicting services in the virtualization edition was discussed
> 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
> thanks.
> -- Anees
> _______________________________________________
> Discuss mailing list
> Discuss@...
> [attachment "Defense4All Proposal Overview - 130903 - Plexxi.pdf"
> deleted by Anees A Shaikh/Watson/IBM]

Discuss mailing list

Join to automatically receive all group messages.