OVSDB Configuration for Hardware VTEPs, with Chandra Appanna from Arista and Bruce Davie from VMware

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.

You can contact Chandra via email at [email protected] and Bruce via

Twitter as @_drbruced.

OVS Orbit is produced by Ben Pfaff. The

intro music in this episode is Drive,

featuring cdk and DarrylJ, copyright 2013, 2016 by Alex. The bumper

music is Yeah Ant

featuring Wired Ant and Javolenus, copyright 2013 by Speck. The outro

music is Space

Bazooka featuring Doxen Zsigmond, copyright 2013 by Kirkoid. All

content is licensed under a Creative Commons Attribution 3.0

Unported (CC BY 3.0) license.