yahoo-eng-team team mailing list archive

[Paul Carver <pcarver@xxxxxxx>]

Public bug reported:

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.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1461133

Title:
  Modular Layer 3 (ML3) Framework

Status in OpenStack Neutron (virtual network service):
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1461133/+subscriptions