Chandra Appanna's guest appearances

Chandra Appanna

OVS Orbit

Larry Peterson

Alex Ellis

Dave Hunt

Josh Bailey

Peter Phaal

Brian O'Connor

Jesse Gross

Greg Ferro

Nicholas Gray

Kyle Mestery

Chang Kim

Cloudbase Solutions

Dave Neary

Frederick Kautz

Simon Horman

OwlTail

Bruce Davie

      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 achandra@arista.com 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.    

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 href="https://ccronline.sigcomm.org/2017/a-database-approach-to-sdn-control-plane-design/" rel="nofollow" target="_blank">A Database Approach to SDN Control Plane Design</a>,” by Bruce Davie and several others, published in the January 2017 issue of <a href="https://ccronline.sigcomm.org/" rel="nofollow" target="_blank">SIGCOMM Computer Communications Review</a>, with the following abstract: <blockquote> 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. </blockquote> 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: <blockquote> 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. </blockquote> Some of the points touched on during the discussion include: <ul> <li> History of the VTEP schema. </li> <li> The relationship of the meaning of “virtualization” in the terms VLAN and VXLAN and VPN, to its meaning in compute and network virtualization. </li> <li> Why use OVSDB VTEP instead of something more general, such as OpenFlow, to control physical switch hardware? </li> <li> Will networking hardware become generally programmable in the future? </li> <li> Similarities of philosophical underpinnings for OVSDB and Arista OS. </li> <li> Potential alternatives, if the OVSDB approach had not been taken (BGP? Ad-hoc scripts?) and existing competitors. </li> <li> State synchronization as the fundamental value of OVSDB. </li> <li> Should databases be used more frequently as a way to implement networking? </li> <li> The process used for developing the OVSDB VTEP schema, compared to the process used for developing IETF specifications. Chandra's viewpoint is worth quoting: <blockquote> 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. </blockquote> </li> <li> Uses of the OVSDB VTEP schema beyond those originally envisioned by VMware. </li> <li> Performance and scale in practice. </li> <li> Future directions for the OVSDB VTEP schema (security? microsegmentation?) and the ease of extending its capabilities. </li> </ul> You can contact Chandra via email at <a href="mailto:achandra@arista.com">achandra@arista.com</a> and Bruce via Twitter as <a href="https://twitter.com/_drbruced" rel="nofollow" target="_blank">@_drbruced</a>. OVS Orbit is produced by <a href="mailto:blp@ovn.org">Ben Pfaff</a>. The intro music in this episode is <a href="http://dig.ccmixter.org/files/AlexBeroza/43098" rel="nofollow" target="_blank">Drive</a>, featuring cdk and DarrylJ, copyright 2013, 2016 by Alex. The bumper music is <a href="http://dig.ccmixter.org/files/speck/42100" rel="nofollow" target="_blank">Yeah Ant</a> featuring Wired Ant and Javolenus, copyright 2013 by Speck. The outro music is <a href="http://dig.ccmixter.org/files/Kirkoid/43005" rel="nofollow" target="_blank">Space Bazooka</a> featuring Doxen Zsigmond, copyright 2013 by Kirkoid. All content is licensed under a Creative Commons <a href="http://creativecommons.org/licenses/by/3.0/" rel="nofollow" target="_blank">Attribution 3.0 Unported (CC BY 3.0)</a> license.

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