Merge "Specification for Neutron Dynamic Routing"

This commit is contained in:
Zuul 2018-02-13 11:02:24 +00:00 committed by Gerrit Code Review
commit e4962d6262
1 changed files with 216 additions and 0 deletions

View File

@ -0,0 +1,216 @@
..
Copyright 2018, Canonical UK
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. Please do not delete
any of the sections in this template. If you have nothing to say
for a whole section, just write: "None". For help with syntax, see
http://sphinx-doc.org/rest.html To test out your formatting, see
http://www.tele3.cz/jbar/rest/rest.html
===============================
Neutron Dynamic Routing
===============================
OpenStack supports dynamic routing, specifically BGP. BGP forms a significant
part of the routing infrastructure for many TelCos and large other
organizations with complex networks. Our charms need to grow support for
dynamic routing.
Problem Description
===================
In a typical setup with Neutron Gateway, infrastructure routers do not have
knowledge of the private networks allocated to OpenStack tenants. As a result,
services external to OpenStack do not know how to route traffic to OpenStack
instances. As OpenStack networks are elastic and therefore can evolve in many
ways, a way of communicating changes between OpenStack and external routers is
needed.
Since networks in OpenStack are self serviced, any addition or removal of
OpenStack network should not depend on network administrators actions. Network
limitations should be set up front. This is further facilitated by the use of
subnet pools in OpenStack.
Other implications include decoupling subnets from layer 2, allowing different
next-hops for floating IPs.
Proposed Change
===============
Neutron dynamic routing solves this problem by introducing a BGP speaker, which
then peers with the existing infrastructure router(s) and announces the
next-hop virtual routers for OpenStack owned networks. This allows dynamic
routing changes to be communicated to the physical infrastructure based on
changes in OpenStack networks. Since OpenStack Networks are managed by users,
address scope limitations need to be in place.
A new charm is proposed called neutron-dynamic-routing which will configure and
deploy the neutron-bgp-dragent (Neutron BGP dynamic routing agent). The
neutron-bgp-dragent is a BGP speaker which can be peered with existing routers
in the BGP infrastructure. This charm will require interfaces for AMQP and
potentially neutron-api-plugin (TBD). For testing purposes it will also make
use of the bgp interface to peer with the quagga charm, both written by Frode
Nordahl (See Testing below.)
Requirements
------------
The charm will need to select an interface on the provider network for
communication with OpenStack. It may also need to select an interface to speak
with BGP routers in the infrastructure.
High availability is accomplished by deploying N number of units of
neutron-dynamic-routing with care for placement on different physical hosts.
This will introduce multiple neutron-bgp-dragents. BGP infrastructure routers
will need to be manually informed of each neutron-bgp-dragent.
IPv4 and IPv6 support is handled with separate bgp-speakers defined for each.
The charm will need to support both DVR and centralized OpenStack routing.
Outside the scope
-----------------
It is important to understand what the OpenStack dynamic routing implementation
does *not* do and lies outside of the scope of this spec.
* It does not provide ingress BGP to OpenStack, it is purely egress
advertisement of OpenStack owned networks.
* It does not automatically advertise all OpenStack networks or whole subnet
pools. A considerable amount of administrator configuration is still
required, including associating OpenStack networks with the bgp-speaker. See
the `Testing documentation https://docs.openstack.org/neutron-dynamic-routing/latest/contributor/testing.html>`__
for a sense of the administrative overhead required.
* It does not provide a mechanism for injecting arbitrary BGP routes (for
example for /32 FIPs). It merely advertises OpenStack networks that have been
associated with the bgp speaker.
Alternatives
------------
Floating IPs, and NAT in general, are one approach to this problem, but there
are couple of drawbacks. For starters, NAT comes with a performance price as
number of connections grows. In cloud, where many VMs can establish connections
to various external peers, this can require significant memory and cpu
resources. Neutron gateway doesn't really scale without manual intervention. On
top of that, if only NAT is used, peers cant really know which instance
established connection, they only know connection came from the cloud. Same
problems apply to DVR.
Static routes on physical gateways are the closest thing to BGP solution. The
only drawback is operational; in case address scope in Neutron changes, these
changes need to be implemented on physical routers too.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
thedac
Additional work:
fnordahl
Gerrit Topic
------------
Use Gerrit topic "<topic_name>" for all patches related to this spec.
.. code-block:: bash
git-review -t dragent
Work Items
----------
**New charm neutron-dynamic-routing**
A new reactive charm will be developed to configure and deploy the
neutron-bgp-dragent.
**Update neutron-api charm**
The neutron-api charm will need to load the service_plugin
neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin and subsequently run
a db migrate.
**Potential need for new neutron-api-plugin interface**
It is unclear at this time if a relationship to neutron-api will be required.
If it is required no layered interface for neutron-api-plugin yet exists and
will need to be created.
**New charm quagga**
For testing purposes the new quagga charm will act as a BGP peer to validate
and test neutron-dynamic-routing. Frode Nordahl has already begun work on this
project: https://github.com/openstack-charmers/charm-quagga
**New interface bgp**
For testing purposes the new bgp interface will define the peering relationship
between neutron-dynamic-routing and the quagga charm. Frode Nordahl has already
begun work on this project: https://github.com/openstack-charmers/interface-bgp
Repositories
------------
A new repository for the neutron-dynamic-routing charm is needed.
.. code-block:: bash
git://git.openstack.org/openstack/charm-neutron-dynamic-routing
A new repository for the quagga charm is needed.
.. code-block:: bash
git://git.openstack.org/openstack-charmers/charm-quagga
A new repository for the bgp interface is needed.
.. code-block:: bash
git://git.openstack.org/openstack-charmers/interface-bgp
Documentation
-------------
An update to the charm deployment guide will be required.
Upstream documentation is found at the following:
https://docs.openstack.org/neutron-dynamic-routing/latest/
Security
--------
The neutron-dynamic-routing charm is dependent on the OpenStack implementation
of BGP. Which uses a simple string as a password.
Testing
-------
The neutron-dynamic-routing charm will need to be tested with a BGP peer. Frode
Nordahl has begun work on the quagga charm which will act as an infrastructure
BGP router allowing for testing and validation.
A mojo spec, or other suitably automated test, will be a requirement for this
feature implementation.
Dependencies
============
None