Despite significant new activity this fall on the NFV specification front, two industry analysts who closely follow network functions virtualization are warning that there are still major gaps in how it is being defined that will slow NFV deployment and undermine its business case.
Caroline Chappell, principal analyst, Cloud and NFV at Heavy Reading , and Tom Nolle, president and founder, CIMI Corp. , both say there still is no clear definition of what orchestration functionality virtual network functions (VNFs) need to run within the network nor any clear assignment of management duties among the different layers of the NFV architecture. Without these key elements defined, network operators who want to deploy NFV will be reliant on vendor-proprietary solutions to plug those gaps.
The two analysts also agree that these two fundamental issues are not being addressed by the new open source group, the Open Platform for NFV Project Inc. , nor were they adequately addressed in the publication of a third white paper from 30 operators involved in the European Telecommunications Standards Institute (ETSI) NFV Industry Specifications Group. (See Open NFV Group Uncloaks Its Platform Plan and ETSI Group to Tackle Thorny Operations Issues.)
"Management is still the black hole of NFV," Nolle tells Light Reading, in his characteristically blunt manner. He believes that the ETSI ISG NFV process itself is flawed because instead of a top-down approach that started with the benefits sought, it has been building a bottom-up architecture, an opinion he has widely shared with the ETSI participants and in his CIMI blog.
Chappell sees the ETSI NFV ISG effort as a high-level affair, lacking necessary details, and is concerned the telecom industry is about to allow its history of failing to address those details repeat itself.
"If you want to be able to do the necessary level of automation and orchestration, there are the details you have to tackle," she comments. "As an industry, the telecom sector has been very bad at tackling details."
As a result, Chappell notes, it has been left to vendors to tackle the details, and that approach results in proprietary deployments that lack the plug and play and interoperability characteristics the network operators claim to be seeking in the move to virtualization.
VNFs left undefined
One of the most fundamental gaps that both analysts cite is in defining what the virtualized network functions will need to run in the expected automated fashion.
"There are still some fundamental questions that are open that are so fundamental it's often even hard to understand why they still exist," Nolle says. "You have to ask the question: What is it we provide to a VNF to allow it to run? How does that which we provide it get produced? How do limitations or characteristics of what we provide it influence the design of the VNF itself?"
There is also a lack of information about what software can be easily translated into being a VNF or a description of what VNF services are, the veteran analyst says. While there is something called a service orchestrator that can build services, there isn't a service data model and no clear method to build a service, he says.
Nolle himself tackled that topic twice, initially in the Cloud NFV vendor ecosystem and, after he left that effort, with his own ExperiaSphere. "I'm not telling anybody I have the right answer -- I have AN answer," he says. (See Answering the NFV Management Challenge and Analyst Unveils Open Source Model for NFV-SDN Management.)
Chappell sees the need for "a recipe book" of VNF requirements.
"I agree we need to understand more about what individual VNFs need if they are running on an infrastructure -- what does the basic requirement look like, how do they behave on that infrastructure?" she says. "What are the specific details of that? All the operators are trying to do it for themselves or through ecosystems. I haven't seen anything being published -- that is the kind of recipe book we need to get to."
The MANO dilemma
The other major challenge is in the network management and orchestration layer, where there are a number of issues still to be addressed.
Chappell has spent much of the last six months looking at the NFV process and particularly examining issues around what's called the MANO layer of the ETSI NFV ISG architecture for management and network orchestration for a report she will produce in November: "Managing and Orchestrating the Telco Cloud: Preparing the NFV Mano and OpenStack for Prime Time."
"We need a clear view of the specific responsibilities of each individual layer of orchestration, for example, what level of resource management is carried out by the VIM and what by the NFV Orchestrator and how the VNF Manager interplays with both -- the deep level of details that we need that is missing," Chappell says, referring to the ETSI NFV ISG architecture as shown below.
The new Open Platform NFV open source group is looking at the VIM, as well as the NFV Infrastructure, but Chappell says their approach is limited.
"OPNFV is only looking at the VIM in the context of OpenStack (the open source cloud standard). But there are a whole lot of other NFV management considerations that OpenStack does not address, and which the community may never agree to include and these are included in scope," she notes. "At the moment, people are putting them in this bucket called 'NFV orchestrator' and there is no clarity whatsoever," the Heavy Reading analyst says. "If OPNFV is not looking at the entire managed stack, but only at the bottom level of it, where OpenStack resides, then I don't think these things are going to easily be resolved."
Looking at the same ETSI diagram, Nolle says there is no connection between the VIM and management: "The resources are part of NFV-I -- well, how do we manage anything?" he asks, leading up to his conclusion that management is still a black hole.
Cause and effect
Nolle and Chappell agree that the industry is facing a process problem. The growing number of groups addressing these complex issues is straining the ability of operators to participate, given their limited resources. Chappell says a number of operators have grumbled to her about the OPNFV -- not for its intent or purpose but because they don't have more people to send to more meetings.
The companies who can afford to participate to the greatest extent are vendors, since they stand to reap business benefits from both influencing and staying close to the development of new specifications. Chappell believes the notion that vendors are deliberately impeding the process "is a myth, it's untrue." But she and Nolle agree that contributing to either the ETSI NFV ISG or the OPNFV at a significant level requires resources that some operators and independent voices don't have.
And Nolle admits he has widely shared his concerns with operators, so they aren't overlooking the issues he raises, just ignoring them. At the same time, he points to his own recent surveys of network operators which show none of them claim at this time to be able to justify on cost grounds NFV deployment in their networks.
That's a direct result of the way the bottom-up process has worked, Nolle says. He is less optimistic than Chappell on what the future holds for NFV. She believes that 2015 will be a pivotal year in which some of the details around VNFs and network management need to be resolved, while Nolle thinks next year should have been when NFV in general was able to flourish.
"By the end of 2015, we could have production NFV running anywhere we wanted to run it," he says. "But what we would need to do to make it happen would not appear to be part of the processes that are under way."
— Carol Wilson, Editor-at-Large, Light Reading