Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
This session will include the following subject(s):
Neutron+SDN: ML2 MechanismDriver or Plugin?:
The Modular Layer 2 (ML2) core plugin introduced in havana replaces and deprecates the monolithic Open vSwitch and Linux Bridge core plugins. It includes MechanismDrivers supporting both of these plugins' L2 agents as well as the Hyper-V L2 agent. Not only is redundant code eliminated, but these L2 agents can now be combined in heterogeneous environments. Additional MechanismDrivers integrate with various types of switching gear. The ML2 MechanismDriver API is intended to support integration with any type of virtual networking mechanism, and work is under way to integrate at least one SDN controller via ML2.
This session will explore the two approaches for integrating SDN controllers with neutron - as monolithic core plugins and as ML2 MechanismDrivers. Topics to discuss include any current technical obstacles to integrating SDN controllers via ML2, advantages of using ML2, and whether the heterogeneity provided by ML2 is useful with SDN. Hopefully the session will lead to consensus on which approach makes more sense for future SDN integrations, and whether current core plugins supporting SDN controllers should eventually become ML2 MechanismDrivers. It will be of most value if maintainers of existing monolithic plugins and ML2 MechanismDrivers, as well as those considering new ones, can participate.
(Session proposed by Robert Kukura)
Modular [L2] Agent:
We now have a Modular Layer 2 (ML2) core plugin that supports a variety of networking mechanisms. Many of those involve L2 agents. These agents typically have similar structure and code. Can they be replaced by a single modular L2 agent? If so, can/should that agent support other functionality beyond L2 (L3, DHCP, *aaS, ...)?
