remembering the management plane

Remembering The Management Plane

[This post was written with input from Martin Casado, Ben Pfaff, Justin Pettit and Ben Basler.]

The Open vSwitch (OVS) project is obviously dear to our hearts at Nicira (and now VMware). OVS is a fairly standard open source project, with many dozens of people from companies around the world contributing patches and reviewing them. However, there is more to openness than just open source software; open protocols (with freely accessible specs) are also important. Of course, Open vSwitch is well known as an implementation of the OpenFlow protocol, for which the specs are freely available. But there is another protocol, arguably just as important as OpenFlow, which is used to manage Open vSwitch instances. That protocol is known as the Open vSwitch Data Base management protocol or OVSDB protocol. While the specification of that protocol can be found within the Open vSwitch sources, it’s a bit of an effort to figure out exactly how it works. With that in mind, as well as a desire to be as open as possible, we decided to publish a spec for the OVSDB protocol in a more familiar and accessible format – an Internet draft.

To be clear, anyone can publish an Internet draft, and that does not make something into a standard. There’s a possibility that this Internet draft may be suitable for publication as an informational RFC. That wouldn’t make it a standard either, but it would at least provide an archival publication mechanism for a protocol that is quite widely used. Whether that happens or not depends on the “Independent Stream Editor”, part of the rather complex organization that handles RFC publication. (See

So, what is this OVSDB protocol? Obviously, you could just go and read our new Internet draft, but here is the quick summary. While OpenFlow establishes flow state in a switch, there’s a lot more to Open vSwitch – indeed there is more to networking – than just setting up flow (or forwarding) table entries. In Open vSwitch, you can create many virtual switch instances, attach interfaces to those switches, set QOS policies on interfaces, and so on. None of these configuration tasks can be done with OpenFlow, so you need a management/configuration protocol to do them.

The OVSDB protocol has been part of the Open vSwitch implementation for many years. It is essentially a general purpose protocol for interacting with a database, and in Open vSwitch the database in question is a set of tables representing switch configuration data. (Some readers may be familiar with of-config – the OpenFlow config protocol – a more recent effort; we believe that protocol could actually be implemented on top of OVSDB.)

To step back for a moment, networking folks often think of any network device as having a control plane and a data plane. Sadly, the management plane has been all too often neglected. OVSDB is a protocol that was created to address that important but neglected aspect of networking. We think that making networks dramatically easier to manage is in fact one of the major benefits of network virtualization. That’s a topic we’ve discussed elsewhere; for now, I’ll just urge readers of this blog to go take a look at our current approach to managing and configuring Open vSwitch instances.

14 Comments on “Remembering The Management Plane”

  1. Baohua says:

    Actually, I agree with the point that the most valuable thing by ovs is not the implementation of OpenFlow (although this is really important), it is the ovs-db.

    There does need a detailed documents on the usage, component, and implementation of ovs-db.

  2. […] submissions lately around the operational plane. One submitted by Martin, Pfaff and crew (read blog or raw draft) around OVSDB which looks […]

  3. […] folks from Nicira (now part of VMware) recently published a blog post discussing the OVSDB IETF draft (see here). It’s a valid point—people get all worked up over OpenFlow, but OpenFlow […]

  4. […] folks from Nicira (now part of VMware) recently published a blog post discussing the OVSDB IETF draft (see here). It’s a valid point—people get all worked up over OpenFlow, but OpenFlow doesn’t […]

  5. EtherealMind says:

    There is a requirement to configure the device itself, in a number of different ways, but you haven’t explained why you’ve chosen to build your own method instead of using OF-COnfig ? Why not use the ONF Standard and thus VMware could integrate with any other vendor & have a better chance of partnering with existing hardware suppliers ?

    It’s an EMC tactic to overlay their own APIs and call them amazing, and then control access to their ecosystem through accreditation. This isn’t open or good for networking. So why do this ?

    • First, OVS-DB predates OF-config by over a year. So the reason “not OF-config” was because at the time we created it, there was no ONF config protocol. In fact, we offered it up to ONF when they started to look at config protocols, but they choose to go a different route.

      Second, the decision to use ovs-db far predates joining VMware, we’ve been using it for years. The protocol itself is just JSON-RPC over a simple data schema. I very much agree that the schema should be standardized, which we will certainly do through IETF. And trust me, as someone deeply involved in ONF (including being on the TAG), it aint’ that open.

      One could easily argue that the path we’re taking is much more open.

  6. […] via Remembering The Management Plane « Network Heresy. […]

  7. BY reading what OVSDB is doing I cann assume a mapping to NETCONF/YANG based configruation management is possible. and as mentioned, there was no OF-Config these days.

    BTW: Can you consider OVSDB as production stable toady. I remember some hick ups in the DB some month (or Years??) ago..

  8. […] Remembering The Management Plane […]

  9. […] same attribute and perform a forwarding action, but it can match and provision a port. That is why management protocols are so […]

  10. <>

    I’m just confused with the phrase “on top of” , do u really meant keeping OVSDB and implementing OF-config or adding of-config rule to “vswitch.ovsschema”. Please confirm

    • drbruced says:

      You can think of implementing a translation layer that sits above OVSDB. It could receive OF-config commands, translate them into appropriate OVSDB operations, pass those on to the database, process the results, and then translate those back to responses in OF-config. So we’d still keep OVSDB with its existing schema, but provide an interface by which devices that speak OF-config could interact with the database via the translation layer. Hope this helps.

  11. <> , I’m little bit confused , Did u really mean we can implement of-config parallel to OVSDB or include of-config rule to “vswitch.ovsschema”. Please clarify

  12. […] Article from Network Heresy […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s