Open Stack

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 <devvesa at 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 at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Jaume Devesa
Software Engineer, Midokura