Since I blogged recently on the challenges operators faced in making a business case for NFV, I’ve gotten quite a few emails from operators themselves. None disagreed with my major point—the current trial and PoC activity aren’t building a business case for deployment—but they did offer some additional color, some positive and some negative, on NFV plans.
In my fall survey last year, operators’ biggest concern about NFV was that it wouldn’t work, and their second-greatest concern was that it would become a mess of proprietary elements, something like the early days of routing when vendors had their own protocols to discourage open competition. The good news is that the majority of operators say these concerns have been reduced. They think that NFV will “work” at the technical level, and they think that there will be enough openness in NFV to keep the market from disintegrating into proprietary silos.
The bad news is that the number of operators who feel that progress has been made has actually declined since the spring, and in some cases operators who told me in April that they were pleased with the progress of their NFV adventures now had some concerns. A couple had some very specific and similar views that are worth reviewing.
According to the most articulate pair of operators, we have proved the “basic concept of NFV”, meaning that we have proved that we can take cloud-hosted network features and substitute them for the features of appliances. Their concerns lie in NFV beyond the basics.
First and foremost, these operators say that they cannot reliably estimate the management burden of an NFV deployment. There is no doubt in their mind that NFV could push down capex, but also no doubt that it would create a risk of increased opex at the same time. They don’t know how much of an opex increase they’d face, so they can’t validate net savings. Part of the reason is that they don’t have a reliable and extensible management model for NFV, but part is more basic. Operators say that they don’t know how well NFV will perform at scale. You need efficient resource pools to achieve optimal savings on capex, which means you need a large deployment. So far they don’t have enough data on “large” NFV to say whether opex costs rise in linear way. In fact, they say they can’t even be sure that all of the tweaks to deployment policy—things ranging from just picking the best host to horizontal scaling and reconfiguration of services under load or failure—will be practical given the potential impact they’d have on opex. One, reading all the things in a VNF Descriptor, said “This is looking awfully complicated.”
The second concern these operators expressed was the way that NFV integrated with NFVI (NFV Infrastructure). They are concerned that we’ve not tested the MANO-to-VIM (Virtual Infrastructure Manager) relationship adequately, and even haven’t addressed the VIM-to-NFVI relationship fully. Most of the trials have used OpenStack, and it’s not clear from the trials just how effective it will be in addressing network configuration changes. Yes, we can deploy, but OpenStack is essentially a single-thread process. Could a major problem create enough service disruption that the VIM simply could not keep up?
There are also concerns about the range of things a VIM might support. If you have two or three clouds, or cloud data centers, do you have multiple VIMs? Most operators think you do, but these two operators say they aren’t sure how MANO would be able to divide work among multiple VIMs. How do you represent a service that has pools of resources with different control needs? This includes the “how do I control legacy elements” question. All of the operators said they had current cloud infrastructure they would utilize in their next-phase NFV trial. All had data center switches and network gateways that would have to be configured for at least some situations. How would that work? Is there another Infrastructure Manager? If so, again, how do you represent that in a service model at the MANO level?
Then there’s SDN. One operator in the spring said that the NFV-to-SDN link was a “fable connected to a myth”. The point was that they were not confident of exactly what SDN would mean were it to be substituted for traditional networking in part of NFVI. They weren’t sure how NFV would “talk to” SDN and how management information in particular would flow. About two-thirds of operators said that they could have difficulties taking NFV into full field trials without confidence on the SDN integration issue. They weren’t confident in the spring, but there is at least some increase in confidence today (driven by what they see as a convergence on OpenDaylight).
You can make an argument that these issues are exactly what a field trial would be expected to address, and in fact operators sort of agree with that. Their problem is that they would expect their lab trials to establish a specific set of field-trial issues and a specific configuration in which those issues could be addressed. The two key operators say that they can’t yet do that, but they aren’t convinced that spending more time in the lab will give them a better answer. That means they may have to move into a larger-scale trial without the usual groundwork having been laid, or device a different lab trial to help prepare for wider deployment.
That would be a problem because nearly all the operators say that they are being charged by senior management to run field trials for NFV in 2015. Right now, most say that they’re focusing on the second half—likely because if you’re told you need to do something you’re not sure you are ready for, you delay as long as you can.
What would operators like to see from NFV vendors? Interestingly, I got an answer to that over a year ago at a meeting in Europe. One of the kingpins of NFV, and a leader in the ISG, told me that the way operators needed to have NFV explained was in the context of the service lifecycle. Take a service from marketing conception to actual customer deployment, he said, and show me how it progresses through all the phases. This advice is why I’ve taken a lifecycle-driven approach in explaining my ExperiaSphere project. But where do we see service lifecycles in vendor NFV documentation?
I asked the operators who got back to me after my blog, and the two “thought leaders” in particular, what they thought of the “lifecycle-driven” approach. The general view was that it would be a heck of a lot better way to define how a given NFV product worked than the current approach, which focuses on proving you can deploy. The two thought leaders said flatly that they didn’t believe any vendor could offer such a presentation of functionality.
I’m not sure I agree with that, though I do think that nobody has made such a service-workflow model available in public as yet. There are at least a couple of players who could tell the right story the right way, perhaps not covering all the bases but at least covering enough. I wish I could say that I’d heard vendors say they’d be developing a lifecycle-centric presentation on NFV, or that my operator friends had heard it. Neither, for now, is true, but I do have to say I’m hopeful.
We are going to large-scale NFV trials in 2015, period. Maybe only one, but at least that. Once any vendor manages to get a really credible field trial underway, it’s going to be impossible for others to avoid the pressure to do the same. So for all those frustrated by the pace of NFV adoption, be patient because change is coming.