OpenSwitch Deep Dive on Software Gone Wild
A while ago I watched a Networking Field Day Extra video in which Chris Young and Michael Zayats talked about HP’s open source initiative – they decided to build yet another open networking operating system.
Obviously I wanted to know more, reached out to Chris, and we quickly managed to set up an online chat resulting in Episode 48 of Software Gone Wild podcast.
We started with a simple question: “Why do we need yet another open networking operating system” and after discussing the benefits of single-file configuration versus spread-out configuration files typically used in Linux environments quickly dived deep into the details of centralized state database used in OpenSwitch, its advantages over message passing mechanisms (nobody mentioned OpenStack ;), and the beauty of notifications provided by OVSDB.
Not surprisingly, we had to touch on the code maintenance process, the governance, and the ways someone could join the project, and concluded with another set of dirty details: how can you claim your software is open-source if it’s programming ASICs through a proprietary vendor SDK? Hint: HP(E) managed to make an interesting deal with Broadcom.
Interested? Visit the project web site, and the podcast is only a click away.
http://openswitch.net/documents/dev/ops-switchd-opennsl-plugin/design
says "It uses open APIs published in OpenNSL SDK (open source SDK for Broadcom switch ASICs)."
But OpenNSL (like Cumulus's switchd) is actually closed-source and proprietary.
Ironically, the "open source" Open Switch ships with 40MB of binary-only, proprietary code, while Cumulus Linux ships 33MB of binary-only, proprietary code.
--
Nolan Leake
co-founder/CTO, Cumulus Networks
The equivalent of Cumulus' switchd in openswitch is the the ops-switchd (also available at the git repo), that uses plugin interfaces to provide the datapath (opennsl being one of them, but there are already plugins to use ovs or p4 as data planes). All of the plugins are open, and the opennsl implementation happens to use a binary blob from the ASIC vendor, but this is their decision as it's their intelectual property. HPE actually worked along with Broadcom to ensure that their kernel drivers where release as GPL in order to enable the community to rebuild the kernel. Other plugins like the P4 for ASICs could be completely open if the ASIC vendor decides to do so.
The statistic about binary proprietary code is quite misleading since this may vary depending of the version of the code shipping, and again this is going to vary on per-platform basis. Even most Linux distributions ship with binary firmware for certain hardware. Unlike Cumulus, anyone can download the code, build it, modify it, and even run the regression test suites. The virtual appliances from OpenSwitch came with full source code (since they don't have ASIC dependencies), where areas Cumulus doesn't make the source for VX available.
Open Source is more than just the code, is about community and direction. OpenSwitch has open mailing lists, IRC channels, code reviews and bug trackers to enable a developer community. While they are challenges to be addressed in how to make the solutions more open with any ASIC, I think the OpenSwitch project has taken the steps in the right direction.
Diego Dompe
OpenSwitch Developer/ HPE Employee
While the names are very similar, they play a different role in the system. Switchd is an API server that clients program with RFC3549 netlink messages over a socket, and it in turn programs the ASIC via a proprietary SDK. OpenNSL is an API server that clients program using OpenNSL-specific messages over a socket, and it in turn programs the ASIC via a proprietary SDK.
Since we're using standard netlink messages, we don't need a separate "ops-switchd" translator to take messages from (for example) quagga to give to the code that actually programs the ASIC.
> HPE actually worked along with Broadcom to ensure that their kernel drivers where release as GPL
We've been working with Broadcom on that as well, as was BigSwitch. We've been shipping the GPLed kernel modules in Cumulus Linux since our first public release in 2013.
> Unlike Cumulus, anyone can download the code, build it, modify it, and even run the regression test suites.
The only part of this that is true is that we don't release our regression test suite. All the code and instructions to build it are available, so anyone interested in building a CentCumulus would just have to remove our trademarks. And multiple people have built things using the code we've released.
--
Nolan Leake
co-founder/CTO, Cumulus Networks
this database centric approach for distributed system is not new, sysdb is around for a decade.
but make use of ovsdb's json-rpc is kind of interesting, isn't this too slow in some case?
Can anyone help me?
jim warner, UCSC
Just the Accton 5712 (under various brands) today. 6712 should be coming reasonably soon.