Show notes
This episode's guests are Bruce Davie, a vice president CTO for APJ at VMware, and Chandra Appanna, an engineer and manager at Arista, who are two of the designers of the Open vSwitch database schema that can be used to control VXLAN forwarding in top-of-rack switches, often called the OVSDB VTEP schema. The discussion in this episode is related to “A Database Approach to SDN Control Plane Design,” by Bruce Davie and several others, published in the January 2017 issue of SIGCOMM Computer Communications Review, with the following abstract:
Software-defined networking (SDN) is a well-known example of a research idea that has been reduced to practice in numerous settings. Network virtualization has been successfully developed commercially using SDN techniques. This paper describes our experience in developing production-ready, multi-vendor implementations of a complex network virtualization system. Having struggled with a traditional network protocol approach (based on OpenFlow) to achieving interoperability among vendors, we adopted a new approach. We focused first on defining the control information content and then used a generic database protocol to synchronize state between the elements. Within less than nine months of starting the design, we had achieved basic interoperability between our network virtualization controller and the hardware switches of six vendors. This was a qualitative improvement on our decidedly mixed experience using OpenFlow. We found a number of benefits to the database approach, such as speed of implementation, greater hardware diversity, the ability to abstract away implementation details of the hardware, clarified state consistency model, and extensibility of the overall system.One of the main points in the discussion is why it makes sense to focus on a database schema, rather than on a protocol, as a way of controlling a network switch, and what it means to use a database to control a network. As Bruce Davie says:
I think there was a little bit of, “Well, here's a tool that's lying in our toolkit, let's try to use it,” but it was also because we spent so much time thinking about the information model. We realized, like many problems in networking, this really is a state synchronization problem, and that's kind of what database protocols do, so let's see if the one we've got can be made to work.Some of the points touched on during the discussion include:
- History of the VTEP schema.
- The relationship of the meaning of “virtualization” in the terms VLAN and VXLAN and VPN, to its meaning in compute and network virtualization.
- Why use OVSDB VTEP instead of something more general, such as OpenFlow, to control physical switch hardware?
- Will networking hardware become generally programmable in the future?
- Similarities of philosophical underpinnings for OVSDB and Arista OS.
- Potential alternatives, if the OVSDB approach had not been taken (BGP? Ad-hoc scripts?) and existing competitors.
- State synchronization as the fundamental value of OVSDB.
- Should databases be used more frequently as a way to implement networking?
- The process used for developing the OVSDB VTEP schema, compared to the process used for developing IETF specifications. Chandra's viewpoint is worth quoting:
To me this felt more familiar, in terms of, this is how the IETF has always tried to do things, “working code and rough consensus,” and that's what happened in this case, right? It solved a real problem, there were enough vendors interested in it. Nicira/VMware kind of spearheaded it, but they built something that others wanted to participate in, and of course we all gave in a lot of inputs. The model definitely does make a lot of sense to the hardware vendors, and that's why it succeeded. We built things in stages, we didn't try to make a perfect solution on day 1, and we actually built working code... I don't find it a severe contrast to how the IETF still wants to do stuff, but, yeah, sometimes it doesn't happen like that.
- Uses of the OVSDB VTEP schema beyond those originally envisioned by VMware.
- Performance and scale in practice.
- Future directions for the OVSDB VTEP schema (security? microsegmentation?) and the ease of extending its capabilities.