• Nurse, pass the paddles please
• Cross-industry initiative to streamline NFVi
• CSPs want to reduce the current 60+ NFVi models to just a handful
• First framework to be shared with the community later this month

It could turn out that 2019 marks the year that NFV got the defibrillator treatment and righted the dysrhythmia that has been affecting the community for the past couple of years. In May we broke the news of the formation of the Common NFVi Telco Taskforce – a group of ten CSPs working within the Linux Foundation Networking (LFN) to create a common NFVi framework, building on preliminary studies done at the GSMA (and which was formally ratified last week). Then we heard news about efforts from the ETSI NFV industry standards group (NFV ISG) to increase focus on NFVi with its forthcoming Release 4 to support lightweight virtualization technologies and optimisation methods to couple VNFs. This is in addition to new features for Release 3 that it hopes will better align the NFV specification with the demands coming out of 3GPP for future 5G standards releases.

The Common NFVi Telco Taskforce is something of a new approach to cross-industry collaboration, with its roots in the GSMA but its growth firmly at LFN. In the space of a couple of months, the Taskforce has increased its CSP numbers to around 16 or so, most of them Tier One operators. It has announced a meeting in Paris (hosted by Orange) later this month where it plans to introduce its initial work to the broader telecoms community.

“Operators see huge benefits of moving from physical networks to virtualised and ultimately to completely cloud native infrastructure,” David Hutton, Head of Networks at the GSMA, told TelecomTV during a briefing call. “The big Tier One operators, who are a lot further along that journey compared to others, are still finding it quite difficult to try and integrate all the new infrastructure into their network. For the different vendor VNFs there’s different requirements that they place on hardware and software, so every time that [CSPs] want to integrate the new components around their network they have to make serious changes to integrate it up and down that particular stack. So for the view that we have – and this is driven by our operators and their requirements – is to try and simplify this process and do some profiling of what that infrastructure would actually look like.”

He added: “I think the hard work and efforts that we're doing now with our major operator support is really going to benefit the industry and the ecosystem as a whole.”

“The infrastructure layer is not going to be the place where we as operators differentiate ourselves,” said Mark Cottrell, AVP Domain 2.0 and Cloud at AT&T and founding member of the Taskforce. “We want to step back and bring together kind of a united front. And the key here is GSMA and OPNFV.”

The Taskforce has a three-step approach to its mission:

“Step one is to get to a really good initial model and that's what we're going to present to everybody in Paris,” explained Cottrell. “Then we start to come up with a set of discrete reference architectures that we can build the VNFs towards and can implement them into our respective networks. Phase three becomes really critical – it's what I call the lifecycle side of this equation, so as the Taskforce fades away over time a feedback loop back to OPNFV to improve the hardening of that certification process becomes critical.”

Faced with countless NFVi architectures today (one estimate puts it at over 60), how far should the industry seek to reduce the number? Is it viable to create a single framework? Probably not, but the Taskforce is certainly looking at single digits.

“I will say most people, when we talk about it, you never hear the word beyond ten,” said Cottrell. “You know, some of us will say we'd like to see one to three, others will say five or six. I'd say less than 10 is probably everyone's perspective.It'll be more than one, but I'll say less than 10.”

Despite the Taskforce being exclusively comprised of CSPs, its members are keen to state that this is for a reason and that vendors will be involved in the bigger NFV picture.

“This is one layer of the bigger programme and LF Networking has all the top 10 networking vendors contributing and very active in pretty much all the projects, including ONAP, OPNFV etc,“ explained Arpit Joshipura, GM Networking & Orchestration, Edge/IoT at the Linux Foundation. So the work here at the at the common NFVi layer at the bottom is also complemented by the ONAP work on top. This collaboration jump starts the vendors to participate. This is a collaborative effort already happening in the Linux Foundation and in GSMA and when you bring it together it just gives a head start to everybody.”

“We will shortly be sending out the reference model to give them some time to know with you and understand it, get their perspectives around it,” said Cottrell. “And then we have an entire day, the first day essentially set aside to review that model.”

He added: “We're targeting the first release to be right around on the model of the reference model. Our goal is to produce at least one reference architecture by ONS in the Fall. And in-between Paris and ONS we will take all their collective input, pick which ones we can fit into that timeframe for Release One of the reference model, and those that we just can't get to, because of the time frame, they'll go into backlog. So it’s like an agile software development mentality.”

“I think that it's really good to have this type of activity between our organisation and the Linux Foundation and use that to build on top of, because I think we're going to see more and more of this,” said the GSM’s Hutton. “In the future, I think the way that networks are being built will be a very different way to the how they were in the past, how networks are being deployed is very different as well. And so we were working very closely to build up that relationship.”

“GSMA is the right place to host it, as it’s a specification, a documentation of architectures,” said Joshipura. “The code and the automation and the scripts are at the Linux Foundation, so they go in the projects themselves. But the best part of this is the loop of validating something that is on paper, to something that's in code is really fast. And I think that's what the industry needs right now.”

The Dublin Release of the ONAP open source project is due in the next few weeks and will have several ETSI specifications already implemented within the code release, mostly looking at MANO and NFVi connectivity.

“The framework of collaboration is in place already,” explained Joshipura. “Our philosophy for the developer community is, if a specification exists, code it; if it doesn't exist, code it and then make sure it's specified in the right place.”

“That's why in Paris, we recognise that there are other organisations, ETSI being one of them, that we need to start to have some discussions with, where we can intake some some information, standards, policies, or vice versa, we can push some information to them,” said Cottrell. “In that collaborative spirit, we'll think the community will figure out where best sits the land, whether it’s with ETSI or with GSMA etc. OPNFV is really more the implementor of these decisions. From a task force perspective we are just at the beginning of that, but I think we've got the framework to make that happen.”