A while ago I discussed whether XMPP is a control- or management-plane protocol (spoiler: it depends). How about OVSDB? Here’s another question from one of my readers:

Why is Openflow considered as control plane protocol and OVSDB management plane protocol if both are relying on SDN controller? Is it because Openflow can directly modify the dataplane?

SDN controllers can use control- or management-plane protocols to get the job done. If an SDN controller is configuring a control plane in an independent device, it’s clearly using a management-plane protocol, if it’s exchanging information with peers or configuring forwarding entries it’s using a control-plane protocol.

The vanilla Open vSwitch implementation uses OpenFlow to configure forwarding entries, and OVSDB to configure interfaces and datapaths (virtual switches) in OVS, resulting in the idea that OVSDB is a management-plane protocol.

However, OVSDB (Open vSwitch Database Management Protocol) is (like its name implies) nothing more than a database manipulation protocol – something like SQL with JSON encoding and a few extensions. You can use OVSDB to query database tables, or to modify (update, insert or delete) their contents.

If you use OVSDB to work with interface or datapath tables, you’re manipulating the device configuration – OVSDB is a management-plane protocol.

Based on my limited understanding of OVS it’s perfectly feasible to use OVS as a traditional bridge and use OVSDB to configure it.

There’s another use for OVSDB: you can use it to exchange MAC-to-VTEP mappings (and a lot of other information) between an SDN controller and hardware VTEP (VXLAN Tunnel Endpoint) gateways. In that case, OVSDB is clearly a control-plane protocol.

To summarize: OVSDB (like XMPP or TCP) is yet another pretty universal tool. Whether it’s used as a control- or management-plane protocol is an implementation detail.

Want to know more?

How about 26 hours of SDN training or tons of SDN resources?