Benjamin Franklin once said, "It's difficult to get 13 clocks to chime at the same time." Projects like Open Platform for NFV (OPNFV) are seen by many of the telcos and other network operators as the only defense against a bunch of NFV-software silos that could make the old days of proprietary router protocols look positively populist. But whether that view can become reality gets us back to Ben's 13 clocks.
Open source challenges
One obvious source of "multiplicity of clocks" is that open source projects are a kind of consensus development. While there are typically guiding agencies at the core of any project, there is also a lot of flexibility at the edges, and even the core of an open source project can suddenly be "forked" and take off in a different direction.
It's this flexibility that allows open source software to respond to market needs, and the model has served Linux, for example, very well. But network functions virtualization (NFV)? Maybe that will be a bit more challenging.
The first challenge is that open source projects are really supported by vendors. Network operators rarely contribute much in the way of developers to open source (Telefonica's recent open sourcing of OpenMANO is a notable exception). Every vendor sees NFV as a combination of the chance for the brass ring and a risk of being dissolved by market forces. They're famous for trying to stack the deck in their favor. Dan Pitt of the ONF just commented on the risk big-vendor influence poses for software-defined networking (SDN); NFV is the same.
The second challenge is that open source projects often take a long time to mature. With nobody likely to emerge the clear winner in an open source-driven market, vendors don't invest a ton of money and effort. One vendor described it to me as "a race to the starting line," meaning that vendors are expected to fund something with the outcome to start everyone at the same point. That doesn't generate much enthusiasm.
Popular open source projects like OpenStack and OpenDaylight have taken years to generate any usable result, and neither of them are really complete at this point. The delays encourage network operators to seek interim or proprietary solutions, which multiplies the challenges of getting a consensus implementation.
The third challenge is that we don't really have a firm specification for NFV to start with. The ETSI ISG, remember, is still working. While their documents have been described as functional specifications, they look in many ways like implementation instructions, which are premature if nobody has done a software design to meet the functional goals of NFV.
Talking with network operators, I've found some pretty significant differences in what they think are the primary functional requirements. What requirements, then, does an open source project build to support? Different visions obviously create different priorities or even different directions.
I'm a big fan of open source software and I use it wherever I can, but it doesn't become telco-ready by accident and all three of these issues will have to be resolved for OPNFV to succeed. Time alone will eventually resolve them all; even a hodgepodge of proprietary temporary visions will still eventually conform to standards set by a solid open source implementation. OPNFV could take some steps to solve them faster.
Steps to solutions
The first step is to lock down the expected NFV benefits by mapping the specific features of NFV at a high level to the things operators think NFV will do for them. Cut capex is one, improve operational efficiency is another, and secure service agility is the third. How do these get done? OPNFV needs to lay that out so that the project can actually do what's needed. Otherwise operators' needs will pull them away to other solutions.
The second step is to focus on the key element of NFV, which is the way services and resources are modeled. Cloud computing has already created an example of a data model (TOSCA, for Topology and Orchestration Specification for Cloud Applications, from OASIS) to describe applications and components and their relationship, and the model can drive deployment and coordinate management. There is already an OpenTOSCA project, and OPNFV should capitalize on it rather than letting themselves become a competitor.
The third step is to specify the critical functional connections of NFV quickly. There are three: How management and orchestration relates to the "Virtual Infrastructure Manager" is one such connection; how operations and management processes like OSS/BSS and network operations centers are integrated is another; and how virtual network functions talk to (or are talked to by) NFV software is the third.
Even if we have an open implementation for NFV, we may have flavors created by "forks" and we may also have proprietary implementations. To make services, resources and practices as portable as possible we need these three functional connections nailed down solidly.
Even where specifications are ambiguous and market forces divisive, a strong implementation that addresses these three areas could almost dictate consensus. That could be enough to establish not only an open source implementation for NFV, but make open source credible for telcos overall. And if open source can succeed in the telco world there's nowhere it can't be made to work.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP