diff --git a/specs/queens/approved/neutron-dynamic-routing.rst b/specs/queens/approved/neutron-dynamic-routing.rst new file mode 100644 index 0000000..7002f28 --- /dev/null +++ b/specs/queens/approved/neutron-dynamic-routing.rst @@ -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 administrator’s 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 can’t 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 "" 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