Gateway

Design specs doc: https://docs.google.com/document/d/1Zae1uaphj_tifFfKKGmEyLgTGR0K5LeP7to4FcfA2-0/edit#

Implementation code review: Addressed by: https://review.openstack.org/79223

= Blueprint Contributors =
 * AT&T Foundry
 * Ericsson

= Abstract: =

Neutron already provides an abstract Router API extension for routing between cloud tenants virtual networks. Its main useful purpose is to enable NATing of IP addresses of the unlimited number of VMs to a limited pool of external/public IPv4 addresses. However, routing between virtual networks subnets adds some complexity (at least for the simple tenant abstract API) in automating the mandatory /subnet IP subnet address design of virtual networks belonging to the same tenant, in sharing various L2 services (usually by configuring helper services in routers), and in moving VMs with zero downtime (usually with extra tunneling if not in the same L2).

We propose to add optional Bridging operations to the Router object so that we abstract both Router and Bridge in a Gateway object managed by Cloud Tenants Admins. This will provide a simple REST interface to bridge virtual networks together and with physical networks while the underlying plugin will focus on programmatically controlling the L2 broadcast regardless of all the heterogeneous virtual networking technologies. This broadcast is usually emulated using L2oL3 tunnels overlays between virtual switches if native tagging is not provided, but other schemes could also be used. With this API, we will be able to easily stitch Neutron Networks to benefit from various existent services in enterprise data centers that are not managed by OpenStack: enterprise DHCP servers, PXE boot software provisioning servers, L2VPN gateways to elastic WANs, to only cite few.

= Use Cases: =

Bridge a tenant network to an external provider network

 * The external provider network is already running L2 services not managed by Neutron
 * Enterprise DHCP server services for tenants VMs
 * PXE software provisioning services for tenants VMs
 * L2VPN gateway services for tenants VMs
 * Internet gateway discovery services for tenants VMs
 * Other L2 services

Merge multiple tenant networks in one L2 network
This merge may be performed without necessarily merging/expanding broadcast domains.
 * Merge operations during virtual networks “live” redesign
 * Tenants networks in same IP subnet but in different locations
 * Moving VMs between these tenants networks while preserving both MAC+IP addresses
 * Sharing an external provider network L2 services (in first use case) between merged tenants networks.

= Concepts: =

We call a Gateway a logical entity that forwards packets across Neutron-provisioned networks regardless if it bridges, routes or tunnels packets at higher layers. It adds another level of abstraction to the existent Router extension API in Neutron to provide optional bridging in first place. Thus, a gateway in bridging mode could optionally run a learning switch function as well as an optional ARP proxy function.

Note: As in any other Neutron object, the Gateway object is an abstract logical object. Therefore, the abstract Gateway API could be realized and implemented in the Neutron plugin using various virtual network technologies. The underlying plugin could configure the Gateway to run in a set of VMs or in a set of name spaces in hypervisors, or in dedicated general purpose servers or dedicated hardware appliances. We could imagine terminating any type of overlay tunnels or ending any native tagging in a Gateway, in order to apply L2 forwarding rules between L2 virtual networks. One L2 virtual network in ML2 could be a multi-segment L2 network that already bridges multiple segments but under the same L2 logical network, i.e. the same Neutron network. A gateway object allow the tenant admin to bridge Neutron networks at the Neutron API level similar to the existent Router object.

{"network_id": “"} {"network_id": “"}
 * POST/GET/PUT/DELETE /tenant//gateway
 * PUT/tenant//gateways//add_gateway_port
 * PUT/tenant//gateways//remove_gateway_port

= View of the logical toplogy and the virtual topology realized by one of the plugins =