OVSDB Configuration for Hardware VTEPs, with Chandra Appanna from Arista and Bruce Davie from VMware - a podcast by Ben Pfaff

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 aretwo of the designers of the Open vSwitch database schema that can be used
to control VXLAN forwarding in top-of-rack switches, often called theOVSDB 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 ofSIGCOMM 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. Networkvirtualization has been successfully developed commercially using SDN
techniques. This paper describes our experience in developingproduction-ready, multi-vendor implementations of a complex network
virtualization system. Having struggled with a traditional networkprotocol approach (based on OpenFlow) to achieving interoperability among
vendors, we adopted a new approach. We focused first on defining thecontrol information content and then used a generic database protocol to
synchronizestate between the elements. Within less than nine months of
starting the design, we had achieved basic interoperability between ournetwork virtualization controller and the hardware switches of six
vendors. This was a qualitative improvement on our decidedly mixedexperience 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 overallsystem.

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 controllinga 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 somuch 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 networkvirtualization.
• 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'sviewpoint 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,” andthat's what happened in this case, right? It solved a real problem,
  there were enough vendors interested in it. Nicira/VMware kind ofspearheaded it, but they built something that others wanted to
  participate in, and of course we all gave in a lot of inputs. Themodel definitely does make a lot of sense to the hardware vendors,
  and that's why it succeeded. We built things in stages, we didn'ttry 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 IETFstill 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 atachandra@arista.comand Bruce via
Twitter as@_drbruced.

OVS Orbit is produced byBen Pfaff. The
intro music in this episode isDrive,
featuring cdk and DarrylJ, copyright 2013, 2016 by Alex. The bumpermusic isYeah Antfeaturing Wired Ant and Javolenus, copyright 2013 by Speck. The outro
music isSpace
Bazookafeaturing Doxen Zsigmond, copyright 2013 by Kirkoid. All
content is licensed under a Creative CommonsAttribution 3.0
Unported (CC BY 3.0)license.

Further episodes of OVS Orbit

Further podcasts by Ben Pfaff

Website of Ben Pfaff