Imagine two people on a long road trip. One of them is very excited because he believes he has figured out a shortcut that will cut days from the journey.

But the other traveler disagrees. The problem, she says, isn't the route. The problem is the destination. They're driving off a cliff.

That's kind of the situation faced in the NFV community today. On the one hand, a group of operators calling themselves the Common NFVI Telco Taskforce (CNTT) -- including some of the biggest names in the industry, such as AT&T, Verizon and Telefónica -- believes it can rapidly speed up NFV adoption by standardizing on a few, simple infrastructure configurations.

However critics say the CNTT is solving the wrong problem. Critics say NFV is fundamentally broken, and fiddling around with specifications and standards isn't going to solve that problem.

Figure 1: The Common NFVI Telco Taskforce (CNTT) is taking NFV on a new journey. Critics say the journey will end like Thelma & Louise.

Deep dive into real-world issues and virtualization deployment challenges with industry leaders. Join Light Reading at the annual Network Virtualization & SDN Americas event in Dallas, September 17-19. Register now for this exclusive opportunity to learn from and network with industry experts. Communications service providers get in free!

The case for simplifying NFVi
The network functions virtualization infrastructure does what the name says: It provides the infrastructure for NFV.

Virtual Network Functions (VNFs) -- like firewalls, VPN gateways and virtual Customer Premises Equipment (vCPE) -- run on top of the NFVi.

The NFVi and VNFs can come from different vendors, and VNFs can still run on the NFVi, so long as they comply with specific standards, in the same way that Android apps from multiple vendors can run on different vendors' phones.

The Linux Foundation's Open Platform for NFV (OPNFV) organization has been developing standard configurations for NFVi and got a little overenthusiastic. They developed 60. That's too many for carriers to keep track of. And so the Common NFVi Telco Taskforce (CNTT) formed in February to simplify the number. The GSMA came on as host of the CNTT later, in collaboration with the Linux Foundation and OPNFV.

The initial proposal discussed three configurations -- one for network-intensive applications, one for compute-intensive applications, and a third for everything else, including IT workloads. The CNTT now says the number is undecided, but it will be fewer than ten.

In addition to simplifying the number of configurations, the CNTT will develop OPNFV certification for VNFs on reference architectures.

Importantly, telcos are in the driver's seat, says Heavy Reading analyst James Crawshaw, who has been following the process closely. "You've got this chaotic situation today where, with the OPNFV project and ETSI NFV, their roadmaps are being dictated by the vendor community," Crawshaw says. "The group has been taken over by vendors because the operators do not have enough knowledgable people to take part."

The CNTT and GSMA are operator-driven, Crawshaw notes. Ten operators were on board CNTT as of April, and they are a roster of the industry's heavy hitters: AT&T, Bell Canada, China Mobile, Deutsche Telekom, Reliance Jio, Orange, SK Telecom, Telstra, Verizon and Vodafone.

"CNTT is finishing the job OPNFV should have done," Crawshaw says.

But Crawshaw's favorable analysis isn't universal.

Going the wrong way
Critics say the GSMA is addressing the wrong problem. The NFVi isn't the problem. The problem is that NFV is too monolithic. NFV was designed to replace hardware appliances for network functions, but it reproduces the hardware's problems in software, critics say.

Modern networks need cloud software to meet the today's business and consumer demands for rapid deployment, scalability, flexibility and robustness. NFV needs to be replaced and rewritten with a more agile cloud infrastructure, suitable to the demands of emerging applications like 5G, say critics.

"Monolithic and cloud don't go together," says telecoms consultant Tom Nolle, president of CIMI Corp. and a longtime critic of the current direction of NFV. "If you want something to be elastic and cloud-ready, you have to break it into components."

In an era when software is moving to lightweight, containerized architectures that break down big applications into tiny microservices, NFV depends on heavyweight applications that run in virtual machines. Because of that architecture, NFV replicates the problems of vendor-dependent, hardware-based networks, even though NFV is software, Nolle says.

The monolithic architecture handicaps carrier efforts to move to cloud networks.

Nolle says the problem is that NFV is fundamentally broken. "It's never been on the right path and it's not going to be on the right path at this point," he says. NFV is designed from the bottom up, starting with functional diagrams. Instead, telco network software -- like modern software -- should be designed from the top down, starting with requirements and building downward to individual components, Nolle says.

A better architecture would be to focus on the desired outcome, which can then be implemented as virtual machines, containers, or in serverless cloud computing, depending on network needs. "Every process can make that decision individually," Nolle says. "But if I write MANO [Management and Network Orchestration] as a box rather than representing the logic, I have just written a monolithic piece of software that can be implemented in one specific way. I can't separate the process."

Because of the monolithic architecture, carriers have difficulty mixing and matching components from multiple vendors -- which was a major point of NFV when an alliance of Tier 1 carriers launched the architecture in 2012. VNFs from one vendor usually require NFVi from that same vendor.

To be sure, NFV has its success stories. For example, AT&T, Colt, Equinix and Turkcell have all recently discussed successful NFV deployments. Just this week, SES said it is implementing NFV on a satellite network for data communications.

But those successes are extremely limited, Nolle says. "If I get one guy ashore at Normandy, have I invaded?" Nolle says.

Next Page: The Path to the Public Cloud

NFV critics have an ally in Neil McRae, BT Group's chief architect. The UK telco recently went with a containerized architecture built on Canonical OpenStack with Ubuntu Linux for its 5G network. The network will start on NFV, but get past NFV to a containerized architecture. "The way I look at VNFs -- and probably many of my colleagues won't agree with me but I don't really care -- I don't think it's the future," McRae told Light Reading late last month.

"With cloud-native microservices, you get true scalability, true CICD [continuous integration and continuous delivery], a true pipeline of being able to deploy features, a true way of really changing from a rack-and-stack model to a cloud expansion model." Cloud-native, containerized architecture is required "in a world where the demands on the network are continually increasing," McRae said.

Caroline Chappell, lead analyst for Analysis Mason's Digital Infrastructure Strategies research program, is also skeptical of NFV's current direction. But she sees a way out, if carriers move network functions to the public cloud, or a platform which fully abstracts network functions from the underlying infrastructure.

Operators already tried to build their own public clouds in the 2000s and early 2010s, competing with Amazon and other hypercloud providers, and failed. "One by one they've been exiting from that market. They've proven they can't build public cloud," Chappell says.

Verizon bought cloud provider Terremark for $1.4 billion in 2011, to become an enterprise cloud powerhouse, and sold the company to IBM six years later, after selling its data centers to Equinix for $3.6 billion.

CenturyLink tried something similar when it bought Savvis in 2011 for $2.5 billion. That acquisition hasn't made CenturyLink a cloud powerhouse, any more than Terremark did for Verizon.

And AT&T launched its cloud compute service, Synaptic Compute as a Service, 10 years ago, following the launch of hosting and storage services and the acquisition of USInternetworking in 2006. AT&T became yet another telco that failed to make its mark in the public cloud.

Now, telcos are looking to NFV to essentially create their own network clouds, which is even more difficult than commodity public clouds, Chappell says. For example, running a disaggregated, virtualized RAN will require 20 different chipsets; how can carriers be sure they're landing the right virtualized function on the right chipset? Likewise, many edge cases will require GPUs rather than CPUs.

The complexity that CNTT is seeking to simplify -- 60 different reference implementations -- is there for a reason, Chappell says. Operator choices of NFVI component vendor, such as NIC card vendor, virtualization supplier and even different versions and configurations from the same vendor can affect VNF performance.

"If you don't have the freedom to make hardware and software choices, where do you get the opportunity to benefit from technology improvements and differentiation?" Chappell says.

She adds, "There is an inherent contradiction in standardizing a reference architecture and also talking about innovation in the same breath."

Instead, telcos may want to consider building a shared, common network cloud, with size, automation and scale to rival AWS or Amazon, Chappell said. However, she added, that could encounter regulatory or antitrust issues.

Or maybe not. Operators, regulators and industry watchers are starting to talk about a need for US operators to share 5G networks. Operators are already sharing networks elsewhere in the world. Why not share network cloud platforms as well?

Alternately, operators could simply migrate VNFs to AWS, Azure or some other commodity cloud platform, Chappell says. "Treat the cloud platform as a modern-day Windows or Linux. It's the modern equivalent of an operating system," she says. Making sure the right workload runs on the right hardware is difficult, but it's a problem that the public cloud providers have solved.

"At what point do operators call it a day and say this is not us, this is not our core business," she says.

Addressing today's problems
Beth Cohen, Verizon cloud technology strategist, acknowledges that cloud is the future. But NFV and CNTT simplification efforts address today's problems.

"I'm a practical person," says Cohen, who has taken a leadership role in CNTT. "What gets me excited about the CNTT effort is that it addresses some real life practical problems that I have personally experienced. That's attractive to me as an operator. I wasn't able to go to my vendors and say to them we have bought into this model, if you want to work with us, start with the model."

She adds, "The intention is to get to the point where we will have developed not only the reference model and reference architectures, but also a method for validation -- test use cases that we can validate against. We are planning to use OPNFV and their resources to create that validation process." Operators and vendors are all trying to solve that problem.

Carriers will still have to do internal testing, but OPNFV validation will give them a head start. "If we can cut out 10 percent of the testing we do, because it's done by OPNFV, that saves everybody a whole lot of time and resources," Cohen says.

Cohen says she believes cloud-native architecture advocates are expecting telcos to move too fast.

"I love cloud native. I think it's great," she says. "But we're taking baby steps here. If you talk to cloud native guys, they say we'll be 100% cloud native in six months. As a telecom, nobody does anything in six months."

— Mitch Wagner Executive Editor, Light Reading