NFV Strategies

ETSI's NFV Group Staying True to Its Purpose

The carrier-led group that launched network functions virtualization (NFV) is staying true to its purpose and scope, but will be spending more time both addressing management aspects of this industry transition and coordinating efforts with the many other groups now engaged in developing NFV, says the chairman of the ETSI NFV Industry Specifications Group.

AT&T Inc. (NYSE: T)'s Steven Wright took over as chair earlier this year, and is leading the European Telecommunications Standards Institute (ETSI) NFV ISG through its second two-year process. And while he isn't denying what critics of the process are saying about its limits, Wright maintains the ISG should remain faithful to its defined scope and work with other groups to make sure "they extend their efforts in compatible directions." (See Analysts Warn of Major NFV Gaps.)

The original scope of the ETSI NFV ISG was deliberately "bounded" to enable the expected work to be accomplished in the original two-year time frame established for the group, he notes. In the past couple of months, the ISG has gone back to its original directives and made some course corrections, Wright says, but it hasn't attempted to broaden the scope. (See NFV Group Finds Its Feet.)

"I think we have corrected most of the things that can be corrected," Wright tells Light Reading in an interview. "There are a number of issues in scope and other topics that we can't correct easily -- but there will be follow-on work and that will be part of the ongoing work of the ISG to correct the discrepancies."

One of the things that may be determined at the group's meeting November 17-21 in Chandler, Ariz., is the extent to which management challenges for NFV are prioritized.

"At this point we have a number of work item proposals that we have started to look at from the last interim meeting in Sophia Antipolis, and some of those touch on these management aspects," Wright says. "They aren't the only thing on the plate, but they are topics some folks are interested in."

Given the broad scope of the original bullet list of NFV goals, assistance from other industry groups isn't unwelcome, he says, particularly in areas where they have expertise and existing standards and information models in play.

"I don't see the ISG doing everything by itself, certainly not in two years or 10 years even," Wright says. Reaching out to these groups "is an area of work that the ISG is going to have to be more engaged in."

That effort should include getting input from other traditional telecom groups with domain expertise, such as the 3rd Generation Partnership Project (3GPP) , the TM Forum , the MEF and other standards development organizations, as well as open source projects, including the Open Platform for NFV Project Inc. .

"We see things coming from different directions -- the open source pieces are building bottom up from what is available in the open source space," Wright says. "But a lot of the other higher layer applications are things where we are going to be looking to other [standards organizations]."

One of the major challenges for the NFV process is that it has a broad impact on the telecom network, and that means service providers have to be broadly engaged in this development process. While operators are used to providing different personnel to different industry organizations -- sending wireless experts to 3GPP or management leaders to the TM Forum, for example -- the transition to NFV is intended to break down service silos and create more horizontal service layers within operators.

"So it's not a matter of getting virtualization experts to learn about management and wireless, it's getting the management and wireless guys to understand how virtualization impacts them," Wright comments. "And then scale that out so we end up with compatible solutions across all the different fields of applications where we need virtualization to apply."

That's why it's essential for the ETSI NFV ISG to be working with other organizations on how all this comes together.

Our "OSS & BSS in the Era of SDN and NFV" event in London this week will closely examine this key transition. Check it out and register here on Light Reading.

Another concern raised by analysts about the ISG's work is that it lacks direct ties to a business case for NFV, something operators need in order to push its development forward, and that its proofs of concept -- more than 25 of which are in development -- also aren't tied to making a business case.

Wright says the PoC process was developed to bring some practical focus to the ISG's work, so the technically possible could be demonstrated and the work wouldn't remain theoretical. As a result, most remain narrow in focus and aren't intended to prove an overall business case for NFV, even if their proponents are touting their business relevance and value.

And while there is the possibility that the PoC process could move more toward advancing interoperability of NFV deployments, there's no guarantee that would push a business case forward, Wright notes. What may be more likely is for the open source platform, such as the OPNFV organization is promising to build, to become the "suitable" platform for validating PoC activity that can tied more directly to a business case.

— Carol Wilson, Editor-at-Large, Light Reading

cnwedit 11/6/2014 | 1:51:14 AM
Re: Yes, But..... Ken, regarding exploration of "a truly multi-SDO top down look at this problem space" - what would that take and is it something that has been done before?
kdilbeck570 11/5/2014 | 6:35:03 PM
Re: Yes, But.....



First I would like to support Steve's assertion that it is going to be critical for SDOs to work together to meet the challenges of delivering an end to end service enablement capability support by NFV and other key technologies. I believe it is key to realize that NFV is not sufficient, in and of its self to deliver to the requirements laid out and it will require the interaction of a number of different disciplines including: network technologies: development, operations and procurement processes; and OSS/ BSS, to deliver agile  services. This fact mandates that SDOs will be required to interact to manage this environment, there will never be one SDO "to rule them all", the problem space is too big, collaboration is the only answer I see. Therefore, I would like to echo Steve's call for collaborative action amongst the SDOs.


TM Forum has taken several actions in support of this. 3 of the 5 catalyst efforts demoed, this June at TM Forum Live! where also ETSI PoC. All four of the catalyst slated for the December Digital Disruption event are exploring management aspects of the ETSI NFV MANO architecture as well as broader management challenges laid out by the ZOOM project.


I not sure it completely addresses the concerns raised by Tom, as it is still a bit bottom up, but TM Forum has liaised a 2-3 documents to ETSI providing a gap analysis and suggested usage of existing TM Forum assets to address the requirements laid out in the MANO documents.  TR238 TM Forum Interfaces: Fulfilling NFV MANO Interface Requirements (NFV(14)000287) is the most recent such document. I encourage other SDOs to follow suit.


It would be interesting to explore if a truly multi-SDO top down look at this problem space could be supported.



cnwedit 11/3/2014 | 2:54:23 PM
Re: Yes, But..... Valid questions, Tom. I'll try to track down some answers.
TomNolle 11/3/2014 | 2:35:56 PM
Yes, But..... I understand Steven's comments about the question of scope versus the time for completing the work.  In fact, that was raised in response to my criticism of the proposed scope of the ISG's work, made in April of 2014.  Certainly it would be impossible for the ISG to solve every network problem.  But there are two questions raised by that truth, and we need to deal with them both, IMHO.

First, should we perhaps be looking at work like the ISG's to be limited to what I've been calling "top-down" issues?  If we're concerned about getting things done in time and proposing that we have to work with other bodies to address related areas, it would seem that a top-down assessment of what's needed should be the first order of business.  The ISG has devoted considerable time to very low-level almost implementation-level detail in some areas.  That seems to me to be beyond the goal of functional descriptions.  Yet in other areas like management, there's no detail at all.

Second, how will the OPNFV contribute to addressing the business case, given that its own charter is to provide a reference implementation for what the ISG does?  If the business case for NFV demands we understand how it relates to management systems (and both "service agility" and "operations efficiency" goals seem to require that), and if the ISG doesn't have management in-scope, how can a reference implementation of the ISG E2E demonstrate the business case?

I'm not trying to be critical here, just trying to understand how we get from where we are to where we say we want to be.
Sign In