The number of significant open source projects related to networking, automation, and orchestration likely number in the dozens. The reasons for this plethora of projects range from politics to pragmatism, and points in between. Whether the reasons are well-founded or not, there’s a practical issue for network operators: dealing with them all. Depending on your open source tool mix, you might — or might not — be able to deliver virtualized network functions in the way that your organization requires.
And so it was that the OPNFV project took shape in 2014. The idea behind OPNFV wasn’t to generate a bunch of code and a new platform that would compete with a bunch of other projects. Rather, the intent was to bring together these various overlapping projects, and validate their suitability for delivering NFV. In chatting with Packet Pushers, Heather Kirksey, OPNFV Director, made the point that OPNFV is focused on NFV through system level integration, deployment testing, and working with upstream communities.
OPNFV has worked hard over the last two years to build relationships with other open source communities. That’s led to a spirit of collaboration across the open source world that is moving NFV forward. Chris Wright, VP and Chief Technologist at Red Hat, in a keynote at the OPNFV Summit on June 25, 2016 said that OPNFV, “is about collaborating. I believe this collaboration is industry wide. So, OPNFV is a critical place where we coalesce industry specific requirements, bring them to all of the relevant communities, do development, bring them back, integrate, test, [and] validate that we have done what we set out to do.”
With this backdrop, OPNFV has announced their third release, Colorado. Colorado grows the capabilities of the OPNFV platform, making it possible to test additional features and scenarios. Key advancements are in the areas of IPv6, security, service function chaining, and VPN.
IPv6. IPv6-only deployments are supported, although not perfectly. As OPNFV explained it, underlay support exists, but not for every platform out there. Overlay support has matured to the point where the remaining gaps have been identified.
Security. As of Colorado, OPNFV repositories have been audited by an external source for vulnerabilities. OPNFV reports that twelve patches related to security were included in the release.
Service function chaining (SFC). SFC is tricky business, the big idea being to move traffic through a specific set of virtual network devices that are not physically inline. With Colorado, service chain support has improved so that now, service chains can be stood up across multiple nodes and controllers, and then tested — helpful in a number of cloud scenarios.
VPN. In addition to the previously supported L3 VPN, L2 VPN support is available. In addition, there is full Quagga router integration for BGP announcement of L3 VPN peers.
There is also full hardware support for ARM hardware as of Colorado, a complement to the full x86 support OPNFV has had right along, promoting end user flexibility in their NFV architectures. FD.io project support, covered in this Packet Pushers podcast, is another Colorado addition.
If Colorado is an indicator, collaboration is the central theme of OPNFV these days. Watching videos from the OPNFV summit, you’ll notice a common theme of, “I play for OPNFV.” Several people from a variety of organizations and open source projects made that statement, driving the collaboration point home. Folks might have varying interests and concerns, but at the end of the day, there’s value in working together.
That’s the second thing this week that makes me a little hopeful about SDN and NFV. If OPNFV continues to move forward, it represents a consensus of how NFV should get done. With that eventually settled, perhaps we can get past the industry fragmentation that’s partly to blame for holding networking back. Wouldn’t that be nice?