I had an interesting exchange with a vendor recently, talking about the future of and leadership in NFV. What made it so interesting was that the vendor echoed a sentiment I’d heard from some operators. His point in essence was that “modernization” was the driver for NFV, that the operators now needed only to prevent falling into the proprietary traps of the past as they embraced the inevitable NFV future.
I’m sure that nobody is surprised to hear I don’t agree with that point. I’ve heard it before and even fallen prey to the view myself. The telco market of old was essentially a public utility, with technology changes coming as the players believed they should. In such a market you could argue that NFV is inevitable. You could also argue that ATM (asynchronous transfer mode, for those who don’t remember) was inevitable. It wasn’t, as history has shown.
So what could vendors do to win? I’ve tried to combine the views of vendors and network operators to create a kind of action list, targeted in particular to the executives who set product, marketing, and sales policies.
First, NFV has to be made into a win-win. There is nothing inevitable about it, nor will NFV success necessarily make a vendor money. The key is going to be to navigate some very complicated points so that a real value proposition can be made, and so that vendors will have the incentive to make it.
Making the business case for NFV isn’t difficult in one sense; we already know that the only thing that can really drive NFV from its current point to early success is operations cost reduction through service automation. The problem for vendors is that only seven or eight vendors can actually provide the essential tools. You have to automate services from top to bottom, end to end, which means you have to start with OSS/BSS processes and work your way down to management processes. Operators know now that this is going to take two or three levels of orchestration, created either by layering interdependent technologies or through a single unified model. If that can be done, then opex savings could easily reach ten cents per revenue dollar, which would be equivalent to more than half the operators’ capital budget.
The problem here is that operations savings through service automation doesn’t really sell new equipment. In fact, you could get a better ROI from not transforming hardware at all, at least for the first four years. There are few vendors who would be willing to do the heavy lifting to drive NFV success when “success” would involve little incremental hardware spending. Server vendors gain little, and network equipment vendors might lose less, but nothing dramatic happens. And worse yet, most of the “NFV success” in virtual CPE is really success that doesn’t drive or even much involve “NFV” in a strict sense. It’s an agile CPE device strategy. You can’t create big vendor wins without major infrastructure transformation.
The only way out of this is to attack a green-field opportunity that has clear credibility, and the best of these is mobile infrastructure. If you want to make a case for your product set in an NFV future, you need to make a case for it in mobile infrastructure. We could easily build 30 thousand edge data centers with 5G rollouts, and that would be enough to get NFV going. However, you can’t do this with servers alone; you need a really strong 5G metro strategy.
Which leads us to the second point, which is that NFV like the cloud is first a virtual network problem and only second a hosting problem. If there’s anything transcendentally frustrating about NFV progress, it’s the second-rate consideration given to virtual networking. NFV, to succeed, builds a carrier cloud. We know from current cloud-provider successes that you need a very strong virtual network model in the cloud. So why is it that we’re doing essentially nothing to build one? Yes, I know that OpenStack includes Neutron as its NaaS tool. Yes, I know that OpenFlow and especially Open Daylight offer the promise of network control at the flow level. But what are we building there? We still have to develop a network architecture. Google’s Andromeda is arguably the centerpiece of Google’s cloud.
Most of the vendors who have full-service NFV support also have an SDN capability. All of them should understand open networking and virtual networks. This understanding has to step from behind the scenes to a prominent position, if for no other reason than that 5G metro deployment will depend on a strong virtual network model, and NFV hosting and carrier cloud are just as dependent. If you have an SDN story, sing it proud. If you don’t, then you’d better get one.
5G presents a special challenge in terms of virtual networking because it’s clear that it won’t be like 4G with IMS and EPC, but not clear just what it will be. We’ll also have a 4G-to-5G transition problem to address, which means that mobility (the big challenge in all mobile networks) has to support an EPC model and some new approach. This should induce vendors to look at metro virtual networking as an open, generalized, problem not a specific one, and to present tools that combine to create solutions, not solutions in isolation.
The concept of “open” is our last point. Vendors must provide an open model of virtual-network and virtual-function architecture. The NFV ISG is slowly recognizing the essential features, but they’re still a long way from a practical structure. The open-source activities we see are all working on the assumption that open-source equals open, and that’s not true. Open-source software can be just as restrictive as proprietary software if the componentization and licensing aren’t done right. Operators are already learning that with VNFs, both of which suffer from proprietary elements and licensing issues.
Modeling is the key to making something open, and we know that from the evolution of DevOps tools for the cloud. There is a superior modeling technology out there in my view—TOSCA—but at the very minimum you’d have to support the notion of “intent models” for each layer of service structure and provide a means to adopt any modeling and decomposition architecture at any point, by simply making a given opaque intent model decompose through another tool. That capability, which I’ve been calling “federation” of model elements, is absolutely critical and yet we almost never hear of it.
If you as a vendor can provide a truly federated approach, you can be as open or more open in a practical sense than an open-source implementation. That means you can at the least provide some differentiation in composable feature/model element terms. If you don’t do that, then you’ll be competing with the variety of operator-supported open-source models, even if they can’t do everything needed.
So there we have it. There’s a pathway to creating a winning NFV story. I think virtually every operator would agree with it. I think virtually every vendor will ignore it, because fiction is always more appealing than the truth. I suspect that a year from now, I’ll be having the very same conversations with vendors about how NFV is justified by “modernization”. Well, at least with those vendors who survive in the NFV space a year from now, and that may be far fewer than we have today.
