OPNFV is a project within the Linux Foundation that creates reference designs and then tests and reports on the integration of disparate open-source networking projects. The OPNFV announced its latest release, called Danube, this week.
One way to think about the OPNFV is as a tinkerer’s garage. It’s a place where people (mostly carriers and service providers) can assemble a variety of open-source networking components and see whether they work together–and if they don’t, to figure out what went wrong.
For instance, what happens when you take this build of OpenStack and run it with this build of OpenDaylight and use a particular set of features? What if you swap out OpenDaylight for Open Contrail? What works and what breaks when you run a new build of OpenContrail with the current build of OpenStack?
OPNFV provides mechanisms to run tests, gather outcomes, and report those outcomes back to their respective projects to help refine them.
“We’re bringing together the various pieces to build next-generation networking built on open-source components,” said Tapio Tallgren, the TSC Chair of OPNFV, in an interview. “Our scope has become more broad, and we’ve put work in the processes that let us connect with upstream communities.”
By upstream communities, he means projects like the aforementioned OpenStack and OpenDaylight, as well as the Open Compute Project (which focuses on hardware design), open source switch and container platforms, DPDK, and open source orchestration and management systems.
“We test features that require all those pieces to work in concert,” said Tallgren.
Case in point is OpenStack Gluon. Gluon uses APIs to enable network services to communicate with Nova, OpenStack’s compute module, without having to go through Neutron, the networking module. The goal is to enable an organization to use multiple controllers within OpenStack, making it more NFV-friendly. (For more on Gluon, here’s a good overview.)
The OPNFV’s Danube release includes reference designs and tests that incorporate Gluon. For a full list of enhancements in Danube, check out the press release.
Should The Enterprise Care About OPNFV?
If you’re in the general enterprise space, this announcement won’t affect your day-to-day existence, at least in the short term.
However, the detailed work required to integrate all these fiddly bits of open source projects should eventually pay off for you in a couple of ways.
First, if you’re a customer of a carrier or service provider (and who isn’t?), the work being done within projects like OPNFV may pay out in benefits such as faster, simpler provisioning; the development of new services; and perhaps even lower costs as carriers and providers take advantage of open source software and commodity hardware.
Second, the effort to integrate open source components up and down the networking stack (hardware, network OSs, VNFs, controllers, orchestration systems, automation tools, and telemetry) may result in Lego-like components that can be assembled and deployed in the enterprise.
OPNFV & ONF: Similar Goals, Different Outcomes
OPNFV isn’t the only project that develops reference architectures and tests integration of open-source components. The Open Networking Foundation (ONF) recently announced an initiative, called the Open Networking Pipeline, to provide instruction sets for service providers to build tools and products from different open source parts.
At present, the ONF is focusing its efforts around ONOS, a data center OS targeted at service providers; and CORD, a project that aims to make service provider and telco infrastructure operate more like cloud services.
The major difference between OPNFV and ONF is that OPNFV develops multiple reference designs and encompasses a wide variety of open source tools, while ONF focuses on more specific, tightly integrated development that’s designed to be productized.
In addition, while OPNFV is part of the Linux Foundation, the ONF is its own separate non-profit entity.