Telecom has a habit of developing its own arcane language that nobody else can understand. The industry appears to have finally outdone itself with the management and orchestration (NFV Managment And Network Orchestration (NFV Managment And Network Orchestration (MANO))) model from the European Telecommunications Standards Institute (ETSI). That's all about to change.

NFV NFV MANO was set up by ETSI as a model to define and develop standards for NFV in service provider networks. There's the growing sense that the real-world technology being developed will move faster than can be accommodated by a structured standards group. It's time to acknowledge that.

“The bottom line is there has been some great work done examining the problem and trying to break it down, but reality is, you can't just design these things in a vacuum,” says Chris Purdy, CTO of service-provider software vendor CENX. “What's really happening is, each operator under pressure to get their VNFs [virtual network functions] running is having to piece together a solution that might look something like MANO, but solves their specific problem.”

It all goes back to the goal: Service providers want to develop NFV technology that enables them to quickly roll out new services on an efficient, open, industry-standard hardware platform. This will enable them to lower operational and capital costs by installing services as software running on standard server hardware, rather than specialized, proprietary equipment.

As Purdy mentions, they're working on that. But it's happening in a more organic fashion than any standards organization, including ETSI, could predict. It includes a combination of internal develop by customers, including the use of open source software, as well as technology partnerships and integration with technology vendors.

One of the ideas behind NFV is to operate more in a cloud model, where innovation happens quickly and new services can be deployed in months, not years.

The NFV MANO model needs to adapt to this new reality. The original architectural concept, developed in 2011, became a roadmap of new technology elements and standards needed for NFV. A lot has changed since 2011 and it's all likely to change again, and it's not clear that the NFV MANO model will — or can — adapt quickly enough.

Service providers and technology vendors with whom I've spoken in recent months say some of the confusion about the future of service-provider NFV stems from the ubiquitous NFV MANO diagram, which can be seen below. The marketing guys got a hold of this slide and promoted it at every NFV conference on earth. It became a sort of Rosetta Stone for NFV.

The truth is that much of this technology does not exist and may not ever exist in the displayed form. Many technology experts say some of the elements in the diagram don't make sense, or need to be developed in a different way.

Last year, SDxCentral contributor Charlie Ashton pointed out the complexity in “Wanted: One Copy of 'NFV Orchestration for Dummies.'” He explained that at a 2014 meeting of the ETSI industry specifications group (ISG) in Okinawa, Japan, participants were searching for greater clarification of what a Virtual Network Function VNF manager (VNFM) does. And who supplies it? The OSS vendor? The supplier of the VNF itself?

It's important to track how this real-world projects are progressing. On Wednesday, I'll be moderating a Webinar Sponsored by CENX, VMware, and Affirmed Networks shows how the technology suppliers are working to fill the gaps in NFV MANO with hybrid solutions.

CENX's Purdy has submitted an interesting slide (below) to explain what's going on as the technology managers grapple with NFV MANO -- and with more advanced management requirements such as Lifecycle Service Orchestration (LSO) that aren't included in the NFV MANO model. In Purdy's view, some of the technology will be developed by existing vendors to fit their customers' needs, meaning the NFV MANO architecture is changing in real time.

CTOs from other technology vendors agree. Prayson Pate, the CTO of Overture Networks, told me that the technology vendors and service providers will have to move forward and adapt technologies that get the job done.

When I inquired further about this, Pate sent me this email:

The famous ETSI NFV architectural framework diagram was created very quickly, and the hosting document (ETSI GS NFV 002) had [the] caveat that the named reference points “are potential targets for standardization.” Many thought that the diagram would change with implementation experience, myself included. Instead, the diagram has taken on a life of its own, and appears everywhere, especially in suppliers’ literature. I did talk to one senior architect who was planning to propose some changes to the diagram, but I am not optimistic regarding his chances. For a new technology like NFV, I think that the IETF model of “rough consensus and working code” has a lot of merit. While the ETSI NFV ISG has recognized the value of proofs-of-concept, I don’t think that they are fully committed to adapting to the learnings of those efforts.

How do we clarify what's happening? It's called technology development. What's clear is that the NFV future will differ substantially from the PowerPoint slides we've seen so far. So I would urge the technology marketing gurus and service providers to focus on what they are doing right now to solve problems, rather than focus on nebulous standards architectures that may never exist.

NFV is a complicated area that's going to require many components including LSO software, NFV infrastructure (NFVi), and integration — with existing optical, Ethernet, and IP hardware, and with OSS and BSS systems. Let's map out how that's happening.

We'll discuss much of this on the webinar on Wednesday.

Photo by insunlight on Flickr, cropped. CC2.0 license.