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]
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
