Re: [openstack-dev] [Neutron] Provider Router topology

2014-11-12 Thread Salvatore Orlando
Hi Jaume,

The concept of provider router is useful as it maps what actually already
happens in several infrastructures. I am not entirely sure that this
however implies we need to expose new API constructs and change the
topology API.

The provider router perhaps can exist in a concealed way, where tenants
still put gateways on an external network, but that would be implemented
with a provider router.

Anyway, I am sure you are aware of the technical debt repayment activities
scheduled for Kilo. Some of them pertain the l3 agent [1], and I'd say
those have the highest priority. If this spec will bring non-negligible
changes in the l3 agent, perhaps it's the case of doing that after the
agent restructuring to avoid conflicts which will slow down everything.

Finally, can you post the specification for this work in gerrit? It seems
it is not the one under the 'edge router' name [2]

Salvatore

[1] https://review.openstack.org/#/c/131535/
[2] https://review.openstack.org/128272

On 31 October 2014 10:01, Jaume Devesa devv...@gmail.com wrote:

 Hi all,

 in Midokura we are working on a blueprint to define a new kind of topology
 for floating ranges, as alternative to external network topology. It is
 based on the idea of a Provider Router that links directly with Tenant
 Routers using /30 networks. It aims to be more pure-floating, helping the
 deployment of floating ranges across different physical L2 Networks. (We
 know there is some interest in this[1]) We think that also it might help in
 add Firewall specific policies at the edge of the cloud and define
 per-tenant or per-network QoS definitions.

 Document[2] is still WIP, with high level ideas and just some API details.
 But we would love to hear Neutron community feedback to go further in a
 steady way. In the implementation level, we are concerned in being
 compatible with current DVR and don't add a new SPOF in Neutron OVS plugin.
 So DVR developers feedback would be highly appreciated.

 We are also interested in chat about it during the summit, maybe during
 the Kilo L3 refractor BoF? [3]

 Thanks in advance!

 PD: Blueprint is here[4]

 [1]: https://blueprints.launchpad.net/neutron/+spec/pluggable-ext-net
 [2]:
 https://docs.google.com/a/midokura.com/document/d/1fUPhpBWpiUvBe_c55lkokDIls--4dKVSFmGVtjxjg0w/edit#
 [3]: https://etherpad.openstack.org/p/kilo-l3-refactoring
 [4]:
 https://blueprints.launchpad.net/neutron/+spec/neutron-provider-router


 --
 Jaume Devesa
 Software Engineer at Midokura

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Provider Router topology

2014-11-12 Thread Jaume Devesa
Hello Salvatore,

thanks for the response. Rest of the responses inline:

El 12/11/14 a las 10:49, Salvatore Orlando escribió:
 Hi Jaume,
 
 The concept of provider router is useful as it maps what actually already
 happens in several infrastructures. I am not entirely sure that this
 however implies we need to expose new API constructs and change the
 topology API.
Our first mistake was to use the word 'Provider Router' for the spec.
Maybe the 'edge' concept was better. We don't mean to add or substitute
functionality for the current Provider Router, but offer a different
topology without the need to define an External Network to provide a
public floating range, or even a public routable for IPv6 use cases.

 
 The provider router perhaps can exist in a concealed way, where tenants
 still put gateways on an external network, but that would be implemented
 with a provider router.
 
 Anyway, I am sure you are aware of the technical debt repayment activities
 scheduled for Kilo. Some of them pertain the l3 agent [1], and I'd say
 those have the highest priority. If this spec will bring non-negligible
 changes in the l3 agent, perhaps it's the case of doing that after the
 agent restructuring to avoid conflicts which will slow down everything.
I am. Actually I'm willing to collaborate on it.

 
 Finally, can you post the specification for this work in gerrit? It seems
 it is not the one under the 'edge router' name [2]
I changed the blueprint URL and I forgot to update this spec. I'll
update it in a few days.

 
 Salvatore
 
 [1] https://review.openstack.org/#/c/131535/
 [2] https://review.openstack.org/128272
 
 On 31 October 2014 10:01, Jaume Devesa devv...@gmail.com wrote:
 
 Hi all,

 in Midokura we are working on a blueprint to define a new kind of topology
 for floating ranges, as alternative to external network topology. It is
 based on the idea of a Provider Router that links directly with Tenant
 Routers using /30 networks. It aims to be more pure-floating, helping the
 deployment of floating ranges across different physical L2 Networks. (We
 know there is some interest in this[1]) We think that also it might help in
 add Firewall specific policies at the edge of the cloud and define
 per-tenant or per-network QoS definitions.

 Document[2] is still WIP, with high level ideas and just some API details.
 But we would love to hear Neutron community feedback to go further in a
 steady way. In the implementation level, we are concerned in being
 compatible with current DVR and don't add a new SPOF in Neutron OVS plugin.
 So DVR developers feedback would be highly appreciated.

 We are also interested in chat about it during the summit, maybe during
 the Kilo L3 refractor BoF? [3]

 Thanks in advance!

 PD: Blueprint is here[4]

 [1]: https://blueprints.launchpad.net/neutron/+spec/pluggable-ext-net
 [2]:
 https://docs.google.com/a/midokura.com/document/d/1fUPhpBWpiUvBe_c55lkokDIls--4dKVSFmGVtjxjg0w/edit#
 [3]: https://etherpad.openstack.org/p/kilo-l3-refactoring
 [4]:
 https://blueprints.launchpad.net/neutron/+spec/neutron-provider-router


 --
 Jaume Devesa
 Software Engineer at Midokura

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

-- 
Jaume Devesa
Software Engineer, Midokura

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev