Fullscreen User Comments
Share on Twitter Share on Facebook Share on LInkedIn Share on GooglePlus
 

Loading…

Loading…

Loading…

Loading…

Loading…

 

ETSI’s network functions virtualisation effort - where does it go now?

signpost

via Flickr © Matt From London (CC BY 2.0)

  • NFV ISG's time runs out at end of 2016
  • Must decide if or how the role should continue
  • Differences over top down and bottom up

The participants in ETSI’s network functions virtualisation (NFV) group (industry specification group - ISG) have completed their eleventh meeting and have rightly been congratulating each other and ETSI on the impact the NFV work has already had. TelecomTV was there and Martyn Warwick was asking the questions.

Amongst the answers it emerged that the group now faces a stretching task - to work out what to do next.  

Originally, the ETSI NFV ISG was specifically formed to be a sort of forum-lite. The idea was to ignite the blue NFV touchpaper and stand back in the expectation that the combined efforts and resources of existing disparate standards and open-source bodies, along with vendors and operators (all cooperating nicely on the joint effort) could incubate the next revolution in telecoms.

Indeed, the original founders, one and all bruised and scarred by years of service in slow-moving standards bodies, saw the ISG as a catalyst. They wanted it to operate only for a limited initial period and not become just another membership club whose main objective was survival.

But of course, the world isn’t that simple.

Bubbling under the back-slapping surface of the most recent ISG meeting (#11) were clearly some fundamental points of difference between participants about the path forwards.

The group’s life has already been extended once because it was felt its work wasn’t yet done, but now it faces decisions about what happens at the end of 2016 when the group is supposed to finally terminate.

Martyn Warwick discussed the ISG’s lifecycle with one of the leading telco ISG participants, Bruno Chatras, senior standardization manager at Orange. (see - Change or continuation? ETSI already thinking about the NFV world after 2016 standardisation)

According to Bruno, having published 50 documents by the end of this year, “we can’t just say goodbye, there you go, you are now on your own.”  But what to do?

One option being discussed, he says, is to extend the duration of the ISG again. Another is to create a partnership between several standards organisations, including open source community organisations, to shepherd the work through.

“Putting this kind of partnership takes time,” he says, so that would have to be decided fairly quickly so that the work of recruiting the various organisations could begin.

There are other options.  “One is to create a new dedicated forum, although personally I don’t think it would be good to create yet another forum. Another would be to create technical committees within ETSI. We are discussing all these options,” says Bruno.

The conversation also touches on the way forward in terms of interoperability between implementations -  should there be standard specifications to define exactly how one component will talk to another, asks Bruno, or should there be a greater reliance on open source code sharing to achieve the same ends.  

There are other points of contention.  One criticism of the work on NFV through the ISG are not to do with the high level objective (service provider transformation to software-driven agility) or NFV’s ultimate utility and beneficial impact.  Nearly everyone agrees on that. It’s about ‘process’ which, it’s being argued, is already having an impact on how quickly and well service providers pick up the NFV ball and run with it.

Observers like Tom Nolle (read his most recent blogs for a much fuller picture) worry that the so-called ‘bottom up’ process of nailing the technical fundamentals and then moving up the stack might turn out to have a drawback or two.

Tom Nolle has long been arguing for a ‘top down’ approach which, as he sees it, sets out business objectives and then burrows down to take care of  technical details. The ‘bottom up’ approach, he argues, risks participants emerging at the end of the process with a collection of relatively un-joined-up technical capabilities and, crucially, without a compelling business case hitched to a commercially driven implementation strategy. Getting the horse in front of the cart is therefore, he implies, an urgent requirement.

Join The Discussion

 
x By using this website you are consenting to the use of cookies. More information is available in our cookie policy. OK