OpenStack Summit April 2013

In this session we will look at modularization efforts for both L2 and L3 services.

This session will include the following subject(s):

L3 API modularization:

The purpose is to discuss issues related to L3 routing provided by separate service plugins as opposed to integrated in core plugins. Even though L3 routing is focus,
this will have relevance to Quantum SI in general.

Things to cover could be API related like if L3 resources become part of core, how will Quantum support those to be provided by other than core plugins? Also, would there be a
benefit in breaking apart some of the API/resources today bundled together as "L3" (e.g. NAT)? Another thing to cover could be handling of state dependencies between plugins (one plugin has state dependent on resource handled by another plugin, floatingip one example), can Quantum support this in generic way?

A service plugin for L3 routing (but also other network services implemented as part of Quantum's SI framework) could be implemented by relying on Nova managed VMs. Connecting and de-connecting such service VMs to different subnets/networks could be simplified if Quantum supported something analogous to VLAN trunks on physical switches. This has been proposed in a blueprint. But how should that be represented/implemented in Quantum, by extending ports or as new resource?

(Session proposed by Bob Melander)

Modular L2 Plugin - Design, Status and Future:

A modular layer 2 plugin (ml2) was proposed and discussed during the grizzly design summit. In contrast to existing monolithic plugins, ml2 uses drivers to simultaneously support an extensible set of network types and to simultaneously support an extensible set of mechanisms for accessing networks of those types.

During grizzly, an initial design for ml2 was created, implementation was begun, and a work-in-progress patch set was reviewed. Meanwhile there has been growing community interest in achieving the goals that the ml2 plugin attempts to address, such as:

* better support for mixing heterogeneous networking technologies
* supporting complex network topologies (i.e. multi-segment L2 networks)
* reducing the amount of code that needs to be written and maintained for each supported networking technology

This session will start with a brief overview of the ml2 plugin's initial goals, its current design, and its development status. This overview will be followed by open discussion of its future in havana and beyond. Possibilities include:

* replacing the existing non-controller plugins (linuxbridge, openvswitch, hyperv) in havana, using their existing L2 agents
* replacing the existing L2 agents with a driver-based modular L2 agent
* supporting new networking technologies in havana via drivers rather than adding new monolithic plugins
* replacing existing controller-based monolithic plugins with ml2 drivers
* replacing the quantum core monolithic plugin interface with a set of more-modular driver interfaces
* extending the quantum API to control physical network topology and other deployment details currently handled via configuration files
* addressing orchestration of higher-level activities that cross the various networking layers and the available mechanisms at each layer

(Session proposed by Robert Kukura)