The Modular Layer 2 (ML2) core plugin underlies the majority of Neutron deployments, including those using the reference Open vSwitch and Linux Bridge L2 agents, as well as various vendor-specific solutions. If you've deployed, operated, or even just used an ML2-based setup, you may have encountered "binding failed" errors, and wondered what could have gone wrong. Or you may just want to better understand how ML2 works and what it can do.
The focus of this session, ML2's "port binding", is the process by which the ML2 plugin selects the mechanism driver(s) and network segment(s) to be utilized for a specific Neutron port. Port binding must succeed before a port will provide the requested connectivity. Its outcome configures the datapath and determines the details needed by Nova or other services to connect to the desired Neutron network. Port binding enables ML2 to support heterogeneous environments. Understanding how it works is critical to getting the most out of ML2.
I will explain why ML2 needs port binding, how it works, and what can go wrong, drawing on real-life examples. We'll start with basic L2 agent deployments, add dynamic configuration of top-of-rack switches, and build up to more complex hierarchical port binding use cases. We'll cover the distributed port support added for DVR. Then we will deep dive into how ML2 port binding addresses the challenges of supporting heterogeneous deployments, such as those involving multiple vendors' network switches, assorted hypervisors, baremetal hosts, containers, SR-IOV, and a variety of network services. Finally, potential enhancements to port binding will be discussed. These include generalized distributed ports, enforcement of SG, QoS and other extension semantics, and the need to evolve the relationship between ML2 port binding and Nova scheduling. Throughout the session, flexibility, usability, complexity, and other potential tradeoffs will be kept in mind.