Luis Gomez <luis.gomez@...>
Just a final note, if the intention for next release is to have a better harmonization among virtualization apps, I think option 1) goes more on the right direction.
toggle quoted message
Show quoted text
From: Luis Gomez
Sent: Tuesday, December 03, 2013 9:28 AM
To: Christopher Price; Suchi Raman; Anees A Shaikh
Cc: <discuss@...>; ovsdb-dev@...; <affinity-dev@...>; opendove-dev@...; Madhu Venguopal; vtn-dev@...
Subject: RE: [affinity-dev] [OpenDaylight Discuss] [ovsdb-dev] [vtn-dev] ODL - Neutron API enhancement to include the southbound driver info
So from what I understand from this and other previous conversations, it looks like there are 2 trends for the Virtualization edition:
1) Run all apps together but try to use only one virtualization at a time, for this we need:
- Virtualization apps do not take any action in the network (i.e. like writing flows) by default but after activating something through their NB API
- Virtualization apps do not share NB APIs, this includes the Neutron and so that Madhu proposal makes sense here
2) Enable (by configuration) one app at a time. In this case the above is not necessary for obvious reasons, however this looks more like a 3-4 Virtualization
editions instead of only 1.
Anyway whatever is the implementation the result looks the same: For Hydrogen release we cannot use more than one Virtualization at a time, am I right?
BR/Luis
From: affinity-dev-bounces@... [mailto:affinity-dev-bounces@...]
On Behalf Of Christopher Price
Sent: Tuesday, December 03, 2013 7:12 AM
To: Suchi Raman; Anees A Shaikh
Cc: <discuss@...>; ovsdb-dev@...; <affinity-dev@...>; opendove-dev@...; Madhu Venguopal; vtn-dev@...
Subject: Re: [affinity-dev] [OpenDaylight Discuss] [ovsdb-dev] [vtn-dev] ODL - Neutron API enhancement to include the southbound driver info
I will not pretend to be an expert in this area as I have had little time to dig into these projects unfortunately.
My reaction/response is therefore one of practicality.
We are so close to the delivery date it feel unreasonable to integrate these functions for the Hydrogen release.
I suggest we aim at delivering option (a) in the 2014 release. I would also support the Affinity API being exposed in the basic release in 2014 as I see value
in a higher level API even in the base release, this would be very useful and interesting to expose to campus and lab environments enabling higher layer app development.
In addition to the basic metadata setting/getting, the affinity engine has a way to set forwarding rules for traffic redirection. This is the feature required
for Radware.
We have a couple of options --
(a) Include affinity in the base edition for Hydrogen release, targeted for small scale testing and campus networks. Design integration between Dove/VTN/affinity
and deliver for next release.
(b) Limit affinity to basic metadata setting/getting and leave it in the virtualization edition. Postpone Radware integration to next release. Design VTN/Dove
affinity integration in next release.
Option (b) is easier and option (a) puts us in better position for next release. This is relatively minor in comparison to the Dove + VTN discussion which is
also in this thread.
On Tue, Dec 3, 2013 at 2:43 AM, Anees A Shaikh <aashaikh@...> wrote:
As we've discussed at some length, Affinity is not in the same category of
function as the virtualization implementations, and also doesn't implement
the Neutron APIs, so I don't think the issue of multiple Neutron API
clients applies to Affinity.
Per Tai-san's note, we're addressing the issue of overlapping control of
the network by i) making the Affinity example flows default-off and
optional, and ii) providing configuration support so that the
virtualization edition runs a single implementation (i.e., one of
VTN/OpenDOVE/OVSDB). (unless something else was discussed in the TWS
call earlier today)
thanks.
-- Anees
discuss-bounces@... wrote on 12/02/2013 07:55:37 PM:
> From: Hideyuki Tai <h-tai@...>
> To: "Ed Warnicke (eaw)" <eaw@...>,
> Cc: "<discuss@...>"
> <discuss@...>, "ovsdb-dev@..."
> <ovsdb-dev@...>, "<affinity-
> dev@...>" <affinity-dev@...>,
> "opendove-dev@..." <opendove-
> dev@...>, Madhu Venguopal <vmadhu@...>,
> "vtn-dev@..." <vtn-dev@...>
> Date: 12/02/2013 07:56 PM
> Subject: Re: [OpenDaylight Discuss] [ovsdb-dev] [vtn-dev] ODL -
> Neutron API enhancement to include the southbound driver info
> Sent by:
discuss-bounces@...
>
> Hi Ed,
>
> Madhu’s proposal focus on the co-existing problem between southbound
> drivers for Neutron Interface.
> I explained about this problem in the following mail.
>
https://lists.opendaylight.org/pipermail/discuss/2013-November/000910.html
> To solve this problem, I think Madhu’s proposal is good.
>
> The co-existing problem between Affinity, VTN Manager, and
> simpleforwarding is a different problem.
> In the Virtualization Edition, more than one application exist, and
> they try to control the same network resources simultaneously.
> Because different applications have different policies on how to
> control network resources, it’s obvious that flow entries installed
> by different applications are inconsistent.
> To solve this problem, we need other solution.
>
> Regards,
> Hideyuki Tai
>
> From: Ed Warnicke (eaw) [mailto:eaw@...]
> Sent: Tuesday, December 03, 2013 11:44 AM
> To: Tai, Hideyuki
> Cc: Madhu Venguopal; opendove-dev@...; vtn-
> dev@...;
ovsdb-dev@...; Kyle
> Mestery (kmestery); <affinity-dev@...>;
> <discuss@...>
> Subject: Re: [ovsdb-dev] [vtn-dev] ODL - Neutron API enhancement to
> include the southbound driver info
>
> So I see the value of this... But what about Affinity?
>
> Ed
>
> Sent from my iPad
>
> On Dec 2, 2013, at 7:57 PM, "Hideyuki Tai" <h-tai@...> wrote:
> Hi Madhu,
>
> I completely agree with your opinion.
>
> Regards,
> Hideyuki Tai
>
> From: vtn-dev-bounces@... [mailto:vtn-dev-
> bounces@...] On Behalf Of Madhu Venguopal
> Sent: Tuesday, December 03, 2013 3:44 AM
> To: opendove-dev@...;
vtn-dev@...;
> ovsdb-dev@...; Kyle Mestery (kmestery)
> Subject: [vtn-dev] ODL - Neutron API enhancement to include the
> southbound driver info
>
> Hi Kyle, OpenDove, VTN & OVSDB devs,
>
> Since we all have integrations completed with the Neutron nb-apis
> and these southbound drivers (ovsdb, open-dove, vtn)
> cannot co-exist in the same virtualization edition, I was thinking
> of extending the Neutron NB-API to include the information
> on which Southbound driver to choose. By doing that, all of these
> bundles can co-exist in the same virtualization edition and
> based on the Openstack/Neutron deployment, the customer can choose
> which ODL-southbound to use. This can be done along
> with the existing configuration that is needed on the OpenStack to
> point to the ODL-Northbound API & the authentication details.
> something like :
>
> [[post-config|/etc/neutron/plugins/ml2/ml2_conf.ini]]
> [ml2_odl]
> url=http://192.168.56.1:8080/controller/nb/v2/neutron
> username=admin
> password=admin
> southbound=[ovsdb | opendove | vtn]
>
> We can ofcourse keep this configuration inside the OpenDaylight as
> well. But, having it done as part of Neutron provides a single
> point of configuration and let the Neutron administrator decide on
> what is to be done, rather than depending on another administrator
> who might handle the Opendaylight Controller.
>
> Please share your opinion and I can get this thing done on the
> Opendaylight side.
>
> Thanks,
> Madhu
> _______________________________________________
> ovsdb-dev mailing list
> ovsdb-dev@...
>
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev
> _______________________________________________
> Discuss mailing list
> Discuss@...
>
https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
affinity-dev mailing list
affinity-dev@...
https://lists.opendaylight.org/mailman/listinfo/affinity-dev
|
