Stop forking NFV! And thrive.

By Chris Buerger

I had the opportunity to participate in Dave Ward’s (CTO Cisco) presentation at the fantastic OpenStack Summit in Vancouver last month. As part of his session, he made a strong statement that warmed my (open source) heart.

To repeat his assertion: “By creating a ‘whole stack’ framework with multiple, loosely coupled open source projects, we can satisfy the need in NFVI for advanced functionality without forking. Stop forking up NFV.”

Let’s unpack Dave’s statement.

In my mind, the ‘whole stack’ framework concept that Dave talked about is squarely aligned with the intent of mid-stream NFV open source initiatives such as the Open Platform for NFV Project. OPNFV’s mission is to accelerate NFV through the creation of an integrated open platform based on the adoption of leading upstream projects such as OpenStack and OpenDaylight (ODL).

The Arno release represents the first step to making this goal a reality by releasing fundamental enabling platform integration and validation technology into the community. Two years ago, Rose Schooler articulated a similar vision at Open Networking Summit 2013 in her announcement of the Intel Open Network Platform. We have been steadily releasing quarterly updates of ONP on Intel’s, and partners such as HP and Oracle are starting to leverage its capabilities.

The main point is the same. While there is no doubt that individual ingredient open source projects are critical and are being integrated/consumed into existing systems (or are augmenting/replacing proprietary solutions), the ‘whole stack’ is the ultimate catalyst and delivery framework to create a complete solution to rapidly deploy SDN and NFV.

The whole stack concept of ‘loosely coupled open source projects’ also has challenges. One challenge is to provide one or multiple common (generally technical) capabilities that act as linkages between the different projects. Think of it like a red thread running through the whole stack.

For Intel, one such connecting capability is the popular Data Plane Development Kit (DPDK), a set of open source libraries and drivers for fast packet processing. This capability is enabled from OpenStack, through ODL and all the way into the Open Virtual Switch (OVS), providing a consistent approach to accelerating packet performance and to optimizing workload placement across the entire NFV/SDN stack.

Having spent many years on both sides of the supply/demand equation for service provider software solutions, I am acutely aware of the benefits that tightly integrated, highly innovative proprietary software products can provide.

I do believe that creating unique NFV/SDN intellectual property (IP) and technical innovation should generate a commensurate financial return. What I think is different in NFV today, and what I believe is center to Dave’s and my argument, is that vendors will not be successful by creating forks of the open source projects making up the entire NFV stack.

The level and timeliness of adherence to the latest open source ingredients has risen to become a primary purchase decision-making criterion. It is perfectly okay to augment open source with unique monetizable IP, just do not attempt to lock-in a customer by having them buy into your fork.

We have already seen this in OpenStack with different commercial solution vendors touting the ‘pureness’ and increasingly short timelines to adopt the latest community releases. I also believe that the same movement will occur as OpenDaylight matures.

Rose quoted Intel founder Andy Grove in her presentation at ONS two years ago. Her point was that with SDN, the networking industry had reached a strategic inflection point that is changing the way the industry thinks and acts.

Now, we are entering a new phase in this process, moving from the open source ingredient level to the complete NFV stack level while elevating the smart integration and non-forked nature of these different components as a main benefit to end-users.  Slightly rephrasing Dave’s statement: Don’t fork NFV if you want to thrive.