Madhu, I don't think this is the right way to handle this -- IMO Neutron
shouldn't need to be aware of details of the virtualization
implementation. In keeping with the notion of Neutron being focused on
providing an abstraction layer, and details and complexity of network
configuration being pushed to the SDN controller, it makes more sense to
me to activate one (or more in the future) virtual network implementations
in OpenDaylight.

thanks.

-- Anees

opendove-dev-bounces@... wrote on 12/02/2013 10:43:31
AM:

From: Madhu Venguopal <vmadhu@...>
To: opendove-dev@..., "vtn-
dev@..." <vtn-dev@...>,
"ovsdb-dev@..." <ovsdb-
dev@...>, "Kyle Mestery (kmestery)"

<kmestery@...>,

Date: 12/02/2013 10:45 AM
Subject: [opendove-dev] ODL - Neutron API enhancement to include the
southbound driver info
Sent by: opendove-dev-bounces@...

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

Anees,

On 12/3/13 9:48 AM, Anees A Shaikh wrote:

Madhu, I don't think this is the right way to handle this -- IMO Neutron
shouldn't need to be aware of details of the virtualization
implementation.

I would say OpenStack already is somewhat aware of the details of the virtualization implementation, since you get to choose between VLAN, GRE, and VXLAN tunneling. So I agree with Madhu that a single place to configure all virtualization details is a good option.

-Lori

In keeping with the notion of Neutron being focused on
providing an abstraction layer, and details and complexity of network
configuration being pushed to the SDN controller, it makes more sense to
me to activate one (or more in the future) virtual network implementations
in OpenDaylight.

thanks.

-- Anees

opendove-dev-bounces@... wrote on 12/02/2013 10:43:31
AM:

From: Madhu Venguopal <vmadhu@...>
To: opendove-dev@..., "vtn-
dev@..." <vtn-dev@...>,
"ovsdb-dev@..." <ovsdb-
dev@...>, "Kyle Mestery (kmestery)"

<kmestery@...>,

Date: 12/02/2013 10:45 AM
Subject: [opendove-dev] ODL - Neutron API enhancement to include the
southbound driver info
Sent by: opendove-dev-bounces@...

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

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

Lori, my understanding of the the multi-segment support in ML2 is
different -- I would say its intent is to allow OpenStack to work over
multiple network types at the same time, not to force the OpenStack user
to "choose" from multiple implementations. It may be that selection of a
single type driver is needed today because the multi-segment use case is
not widespread. I would of course defer to our local ML2 expert on this
(ahem, Kyle).

But I still stand by the original point about having this configuration be
done in OpenDaylight, not OpenStack -- I am not arguing we should not have
it in one place, only *which* place.

thanks.

-- Anees

Lori Jakab <lojakab@...> wrote on 12/03/2013 01:36:49 AM:

From: Lori Jakab <lojakab@...>
To: Anees A Shaikh/Watson/IBM@IBMUS, Madhu Venguopal

<vmadhu@...>,

Cc: opendove-dev-bounces@..., "ovsdb-
dev@..." <ovsdb-dev@...>,
opendove-dev@..., "vtn-
dev@..." <vtn-dev@...>
Date: 12/03/2013 01:37 AM
Subject: Re: [ovsdb-dev] [opendove-dev] ODL - Neutron API
enhancement to include the southbound driver info

Anees,

On 12/3/13 9:48 AM, Anees A Shaikh wrote:

Madhu, I don't think this is the right way to handle this -- IMO

Neutron

shouldn't need to be aware of details of the virtualization
implementation.

I would say OpenStack already is somewhat aware of the details of the
virtualization implementation, since you get to choose between VLAN,
GRE, and VXLAN tunneling. So I agree with Madhu that a single place to
configure all virtualization details is a good option.

-Lori

In keeping with the notion of Neutron being focused on
providing an abstraction layer, and details and complexity of network
configuration being pushed to the SDN controller, it makes more sense

to

me to activate one (or more in the future) virtual network

implementations

in OpenDaylight.

thanks.

-- Anees

opendove-dev-bounces@... wrote on 12/02/2013

10:43:31

AM:

From: Madhu Venguopal <vmadhu@...>
To: opendove-dev@..., "vtn-
dev@..." <vtn-dev@...>,
"ovsdb-dev@..." <ovsdb-
dev@...>, "Kyle Mestery (kmestery)"

<kmestery@...>,

Date: 12/02/2013 10:45 AM
Subject: [opendove-dev] ODL - Neutron API enhancement to include the
southbound driver info
Sent by: opendove-dev-bounces@...

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

_______________________________________________
ovsdb-dev mailing list
ovsdb-dev@...
https://lists.opendaylight.org/mailman/listinfo/ovsdb-dev

Anees, Lori,

Yes. I had the same conflicting thought within me when I proposed this & hence kept both the options open.
We can infact keep this an ODL specific configuration if it is understood that it is a deployment headache
to configure neutron specifics in 2 places.

So, if we have a concensus around this, atleast on the Neutron integration front, we can have this configurable
on the ODL side and that will decide the southbound to be used for handling the neutron calls.
( I will also add a NB-API for that which can be triggered at runtime if need be ;) ).

Thanks,
-Madhu