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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : [email protected]
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
