Comment 0 for bug 1461133

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.
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.

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.