Network Functions Virtualization (NFV) is one of several technologies that operators are hoping will improve their profit on infrastructure investment. NFV itself was launched to reduce capex by substituting generic hosted functions for embedded-appliance-based functions. NFV’s benefit expectations have evolved since to include, and even emphasize, operations efficiency and service agility.
The evolution of expectations doesn’t necessarily drive collateral evolution of capability, which I’ve noted in the past. Last year operators told me that none of their trials of NFV had proved a full business case for deployment. Early this year they said that they were integrating more operations practices and processes into the trials, and most were hopeful this would resolve the benefit issues. Even though it’s only the end of April, they’re still evolving their view of NFV and I think it’s interesting to see where it’s headed.
The most significant point I’ve learned is that about 80% of operators’ NFV trials are characterized by operators themselves as “proof of technology not benefits”. This isn’t a return to the 100% “my trials won’t prove a business case” but it does seem pretty clear that hopes that additional scope for current PoCs and trials would justify deployment aren’t yet realized.
A couple of operators were very candid in their comments. The problem, they say, is that the trials aren’t really doing much to operations at all. Vendors, who in fairness are probably influenced by the ETSI vision of management and operations integration, have promoted what can be called the “virtual device” model of management. Virtual functions, under this model, are managed by adding management components that mimic the management interfaces and behaviors of the original devices.
This seems very logical on the surface. If you want to validate NFV technology you need to contain the impact on surrounding aspects of your network and business or you end up with a “trial” that includes everything. The challenge is that if you are mimicking current device management, then it’s hard to demonstrate much in the way of operations efficiency gains. In fact, you’re likely to create additional operations issues.
Early trials of the virtual device model show that you can manage a virtual device through existing interfaces, with existing tools, only to a point. There is a kind of border you’ll need to cross in this situation—the border where virtual functions are hosted on or connected through real resources. The management of those resources tends, in early NFV trials, to be separate from the management of the virtual functions. The challenge, according to operators, is that separation means that resource management in addition to function management is needed, and problem resolution across the border is more difficult than expected.
A few of the operators attribute all of this to a lack of service lifecycle management focus. In order to assess NFV benefits, you’d have to be able to test NFV from the conception of a service to the realization as a product to be sold and paid for. Three quarters of trials, according to operators, fail to provide any such scope and so it’s difficult to assess what the total cost and total agility-driven revenue benefit might be.
Most operators now seem to believe that the problem isn’t NFV per se, but the fact that NFV has to be fit into a larger service revolution. “I’m not interested in building my business around NFV,” said one, “but I’m very interested in building NFV into my business.” The challenge for operators is that while there is an NFV architecture (even if it’s operationally imperfect or at least not validated) there’s nothing above they can play with.
What I see now is something like the “transformation” age of operators eight or ten years ago. At that time they all were looking at business model transformation aided by technologies. I looked back over the presentations made at that time and found striking similarities with the presentations on current operator goals for building that mysterious layer above NFV (and SDN). Nothing much came of those old adventures, of course, and that has a lot of operators worried. They need something complete and effective in play within two years on the average, and they’re not only unsure where it will come from, they aren’t confident they can describe it fully to prospective sellers.
There are people who see this as a failure of NFV, even within the operator community. About a quarter of Tier Ones seem to have scaled back considerably on their NFV expectations. I’ve had my own doubts about the scope of the ETSI work—I’ve argued from the first that the limitations in scope risked isolating NFV from most of the benefit sources. I still feel a broader model would have been better, but I have to admit that it would have taken longer to do and in the end might not have accomplished any more than that which has been done by the ETSI ISG to date.
So what’s the problem? I have a sense of inevitability here, I guess. The constriction of profits between a falling revenue-per-bit line and a slower-falling cost-per-bit line is a systemic problem with roots that go way beyond network technology and operations or business practices. It may not be possible to solve it completely, and even some operators now admit that. Regulators may have to accept the very kind of consolidation that the rejection of the Comcast/Time Warner deal would have created. Users and OTT players may have to accept that there will not be continued improvement in speed and quality, and that in fact congestion online may become the rule.
That’s what these new high-level visions are hoping to avoid. A bit less than half the operators seem to have at least skunk-works projects underway to advance a new service architecture at the highest level. In a goal sense, most of these new architectures aren’t demanding NFV or SDN or the cloud, but they are all defining objectives it would be hard to meet without all three. In fact, what these operators seem to be creating is a kind of Unified Field Theory for networking that harmonizes all three.
For vendors this poses an enormous risk and opportunity at the same time. Much of the work involved in PoCs and NFV trials up to now isn’t going to pay off in direct deployment. Much of the work needed to drive significant network transformation will have to take place outside the NFV, SDN, and cloud processes. But remember that about 20% of trials are considered to be making useful progress. We do have NFV vendors who are successfully (if, in operator views, too slowly) expanding their scope to grasp at the borders of NFV and whatever is above it. This is where big vendors will have the advantage, because they’re going to have to take a big bite of complexity to get a big bite of benefits. And only a big benefit case is going to transform networking.