Even if you're not attending the inaugural NFV World Congress this week, you might still hear the sound: the drumbeat welling up from San Jose, the sound of carriers chanting for network functions virtualization (NFV) now.

NFV is different, as networking initiatives go, in that it's being driven by the customers — telecom carriers and cable providers. They invented the concept more than two years ago and have now formed the Open Platform for NFV (OPNFV) project to build a reference model of the architecture.

NFV World Congress opened on Tuesday with an OPNFV workshop, where carriers in various sessions hammered on the factors driving them toward NFV. The points certainly aren't new, but it's clear the carriers still want to make sure their message gets heard and that OPNFV doesn't dissolve into a morass of committee paralysis and vendor self-interest.

If you're at the conference this week, or watching the live stream, these points are the subtext to everything that's being discussed. Here's what carriers say they want:

Common Ground

"The more we converge, the more we don't fail," said Margaret Chiosi, distinguished network architect at AT&T Labs and OPNFV's president.

Telecom networks are unique like snowflakes, and that's one factor preventing carriers from enjoying the benefits of commodity gear. Nearly all enterprises can use the same type of server, because companies' requirements don't vary much on a high level. Telecom needs to find its way into that state, she said.

If NFV can point the way toward common goals and architectures, the reward would be commoditized equipment. Which leads to an even bigger goal for NFV:

Cost Savings

Carriers do see NFV as a chance to whittle away at the margins they've been paying equipment vendors. It's a point brought up frequently by Chiosi — who is speaking at NFV World Congress today at 11:20 a.m. Pacific (did we mention we're providing a live stream of this stuff?).

An End to Vendor Lock-In

Everybody in networking talks about interoperability. What customers have really wanted, though, is for network gear to be interchangeable, where any given vendor is, frankly, expendable. Carriers see a chance to make that happen with NFV.

NFV "is going to make it much more possible to gain new partners and bring in new services from new suppliers very quickly," said Bryan Sullivan, director of service standards for AT&T.

Luigi Licciardi, a Telecom Italia vice president in charge of technology planning and standards, brought up this point in regards to the next-generation core for the mobile network. He said the interfaces aren't open enough — neither upstream to the application nor downstream to the equipment's element management systems — and that his team is "not satisfied with the answers we have on this issue from the traditional vendors."

Agility

It has become a cliche of a term, but the webscale players have agility, and the carriers don't. In a telecom network, turning up a service takes planning, expenditures, and maybe even internal political maneuvering. NFV promises to let network functions blink on and off automatically like Christmas lights.

"The No. 1 opportunity is really agility," Sullivan said. "To turn up some circuit across the country, it should be minutes instead of months."

We're going to cheat here and also use "agility" to refer to the speed of software development afforded by DevOps.

"Our world is a world that is based on old issues, so we have to renew our culture, in terms of developing, understanding, and using software in the proper way," Licciardi said.

But it's important to fully understand why carriers lack the DevOps kind of agility. It's not entirely due to culture. A telecom network is a public utility that has to remain standing, even today. Which brings up one of NFV's more subtle requirements:

Carrier-Grade Operations

The telecom network is still engineered for five-nines reliability (99.999 percent uptime). This is where telecom and cable providers' needs diverge from those of the enterprise or the hyperscale cloud players. It can take some work to get open source organizations to understand that "carrier-grade" is not just an affectation.

Heather Kirksey, OPNFV's director, related her experience in explaining "carrier-grade" to the folks at MongoDB, her previous employer. MongoDB was accustomed to recovery times measured in minutes. You can't do that in telecom.

"I said, 'Guys, imagine if no one in the northeast can make a phone call — for five minutes,'" she said. "It's not because we're fuddy-duddy about networks. It's because we're public infrastructure."

"Carrier-grade is actually very fundamental. Reliability, performance, security, policy management — all of these things have to be factored into the open source projects we're using at OPNFV," Sullivan said.

There's hope. When carrier-grade jargon gets translated into normal language, some of these requirements, like fault tolerance, start sounding reasonable to enterprise engineers, said Dave Neary, who works on NFV and SDN community strategy at Red Hat.

It's crucial to bridge that communication gap, Licciardi said.

"One of the missions that I think OPNFV should have is creating a community of professional developers that know exactly what the requirements are — reliability, interoperability — of the software they are developing," Licciardi said. "Creating this sensibility among the developers is one of the most important missions."

(Photo: From left, Donley, Sullivan, and Licciardi.)