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@...>
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
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
[attachment "Defense4All Proposal Overview - 130903 - Plexxi.pdf"
deleted by Anees A Shaikh/Watson/IBM]
