Icehouse Design Summit

This session will include the following subject(s):

L2 VPNs as a service:

This is a discussion of L2 VPNs, such as GRE tunnels L2TP, and even VLANs, and how we might implement an API for them in Neutron.

L2 VPNs are different from L3 VPNs in that there is no address on the inside end of the connection, the end which transmits content between the tunnel and the Neutron network. In some encap cases, such as VLANs, there isn't even an IP address on the outside of the tunnel.

There are API models we already use have some parallels to L2 VPNs - both routers and provider networks have some similarities - but neither is a perfect match. Routers typically provide an addressed internal port and provider networks are statically created by config as they relate to the hardware setup of the system.

This session will review a few possible models for how we might describe L2 VPNs with objects and REST APIs, followed by a general discussion.

(Session proposed by Ian Wells)

Gateway extension API proposal:

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.



(Session proposed by Racha Ben Ali)