[RFE] Supporting multiple L3 backends

[Paul Carver]

There are a variety of hardware and software options available to handle layer 3 (routing) in Neutron environments with various tradeoffs. Currently a single Neutron instance can be configured to support only one routing mechanism at a time and this leads to a need to build multiple OpenStack zones based on different requirements.

<snip>
This RFE is analogous to the ML2 framework. I would like to see a standard vendor neutral framework/API for creating/maintaining L3 routing constructs with a standard way for vendors/developers to build mechanism drivers to effect the desired routing on a variety of hardware and software platforms.
In terms of broader scope (perhaps not initial implementation) there are a number of L3 related developments taking place that could benefit from the logical (aka "type") constructs from the implementation (aka "mechanism") constructs. e.g. BGP VPNs, IPSec/SSL VPNs, Service Chaining, QoS.
<snip>

The vision here is that the OpenStack community would standardize on what virtual routers can do, then individual companies/people with an interest in specific L3 implementations would build mechanism drivers to do those things. An essential criteria is that it should be possible to mix mechanisms within a single OpenStack zone rather than building separate building entirely separate Nova/Neutron/computenode environments based on a single L3 mechanism.

Some examples of ways to handle L3 currently: L3 agent on x86, SDN software Contrail, Nuage, NSX, OVN, Plumgrid, and others, in hardware on a variety of vendors' switch/router platforms Arista, Cisco, others.

[Kyle Mestery (mestery)]

We currently support L3 service plugins, so in effect we already have a standard API for integrating L3 routers. What you want here is the ability to run multiple L3 routing plugins at the same time.

[Armando Migliaccio (armando-migliaccio)]

I changed the bug title: ML3 framework is one solution to your problem. Let's not confuse the solution with the requirement.

[Armando Migliaccio (armando-migliaccio)]

I think that the need is clear, and I am +1 with that. Whether this is addressed with something like ML3, flavors etc. That is a design discussion.

[Kyle Mestery (mestery)]

Agree with Armando. The need is clear, what's unclear is the proposed approach.

[Paul Carver (pcarver)]

I agree too. I'm just trying to find time to put all my thoughts together into a coherent whole. Armando's comments have been very helpful in pointing out the gaps in some of my assumptions but I haven't had the free time to really focus on rearranging my ideas. I need to separate out issues that are specific to our OpenStack deployments from issues that are generally applicable to everyone with similar NFV use cases.

[Isaku Yamahata (yamahata)]

some links for reference

etherpad for collecting use cases as first step to define a set of problems to solve
which will be base for discussion.

https://etherpad.openstack.org/p/neutron-modular-l3-router-plugin-use-cases

ML3 spec proposal: L3 plugin: modular L3 router plugin

https://review.openstack.org/#/c/105078/

[Kyle Mestery (mestery)]

Triaged, the use case is clear and we all agree moving forward is good.

[Armando Migliaccio (armando-migliaccio)]

@Kevin: fancy chewing on this one? After spending some time on this and after looking at flavors, it's increasingly clear to me that Flavors, plus making the L3 plugin adopt a service type framework is a step in the right direction to address this need.

[Henry Gessau (gessau)]

ML3?

[Henry Gessau (gessau)]

Ah, I see the old ML3 work was referenced by Isaku.

[yong sheng gong (gongysh)]

I think it should be in flavors direction. First make the L3 as an service type with provider variety, and then put it into flavor framework

[Isaku Yamahata (yamahata)]

Restored https://review.openstack.org/#/c/105078/ to reboot the discussion for Mitaka.

[Isaku Yamahata (yamahata)]

restored https://review.openstack.org/#/c/134997/ to reboot coding effort for Mitaka

[sean mooney (sean-k-mooney)]

hi i was wondering if there had been any progress made on this item?
looking at the patchset posed by isaku the work still seams to be stalled is that the latest review?

[Armando Migliaccio (armando-migliaccio)]

status update: http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-01-28-22.20.log.txt

[Rui Zang (rui-zang)]

Kevin Benton, from the neutron drivers team meeting log I saw you have already had something for this RFE. Could you share it? Because I think many people (surely including me) are interested in contributing.

[Armando Migliaccio (armando-migliaccio)]

Any experimental/isolated code will have to go is as 'Partial-implement' or 'Related-blueprint'