[ovs-dev] OpenSwitch Project

Zayats, Michael michael.zayats at hpe.com
Tue Oct 13 17:36:44 UTC 2015

Following the launch of the OpenSwitch project (www.openswitch.net), I would like to address the Open vSwitch community, explain how OpenSwitch leverages and aligns with OVS and start a discussion about a collaboration strategy.

OpenSwitch, OPS for short, is built to operate physical switches in the data centers and beyond. 
While some essential blocks of L2/L3/manageability are already available at git.openswitch.net, we would like to turn it into a fully featured NOS, addressing wide variety of use cases.
Eventually it will be serving both cloud-scale and more traditional L2/L3 environments, and should be useful for those who are looking for complete programmability, as well as those who would like to manage switches using CLI, GUI and other familiar mechanisms.
Above anything else, we are looking to make it community driven, combining the forces and collective minds of all interested parties in order to make the best open source NOS possible.

As we recognized the fundamental importance of virtual switching as a new edge of the network, we made a conscious decision to align the architecture and the operational model of OpenSwitch to OVS. 
Those who invest in the operation or development of OVS should feel at home when they deal with OpenSwitch. 

If you look at http://www.openswitch.net/documents/user/architecture, you will see that OPS heavily builds on the strong foundation of OVS. 

OPS uses OVSDB-Server for all  system configuration/status/statistics, facilitating all pub/sub communication inside the system, from the temperature of the box to BGP routes.

The OPS schema is not designed around any particular ASIC, but rather extends the one from OVS - we tried keeping the same syntax and semantics for the shared tables/columns/values. 
We believe we were successful in vast majority of the cases.

OVS libraries are used for all OPS daemons.

ovs-vsctl and other utilities were extended to support additional functionality required by the physical switch.

ovs-vswitchd is used as a basis for ops-switchd, preserving and extending the ofproto and netdev provider interfaces to interface ASIC specific drivers.

The test framework is based on Mininet and when combined with Docker allows testing of the control plane using complex topologies in the convenience of one's laptop. 
The same frameworks and tests are leveraged by the CIT infrastructure as well.

The OVSDB protocol is already used to connect all OPS daemons to the database, and it's envisioned to provide great extensibility outside of a single OPS entity. 

We added a Python based REST daemon that exposes OVSDB server to HTTP clients, allowing interfacing to OpenSwitch using anyone's favorite languages/frameworks.

Given that OVSDB-Server is such a central piece of the OPS architecture, several of our developers started looking into optimizing IDL libraries as well as improving the protocol and the server. Some of the patches resulting from this effort are in flight on this mailing list and multiple more are being prepared/discussed.

Now, from the present state to the future.

As a part of the initial OPS buildout, we took a snapshot of OVS from about February of this year and made the required modifications. However, there is clearly no intention to keep it this way. 
We would really like to develop all shared components upstream in OVS, contributing to the richness of both systems.

Obvious parts that we would prefer to discuss and develop upstream are OVSDB-Server, C and Python IDL libraries (GoLang is on the radar), OVS libraries, ofproto layer providing OpenFlow implementation, utilities etc. OVN components would eventually make their way into the list as well.

In order to make it happen, we need a collaboration with OVS community. 
Specifically we would like to discuss how to make OVS extendable - allowing physical switching aspects to effectively extend shared components in a decoupled way. 

We would really like to hear what Open vSwitch community with its thought leaders thinks about it. 

Please share what's on your mind and let's make the networking industry better together!


Michael Zayats

More information about the dev mailing list