You could sum up any evolution of network services or infrastructure in a pseudo-equation: Business case equals benefits divided by the sum of cost and risk.
If you want to justify massive changes -- a revolution -- you need massive benefits, and for network functions virtualization (NFV) that means an implementation that has a very broad scope. The implementation can come from a single vendor or a well-integrated community or partnership, but whatever the source it has to hit all the sweet spots of transformation or it may never happen.
What does a complete NFV solution look like?
It's easy to say what's required to make NFV a success -- make the business case. The challenge is that there are three NFV benefits on the table: capex reduction, opex reduction and service agility or new revenues. Network operators are in the business of networks and services, and it's not a surprise that all these things cut across their entire operation. Nobody would expect a bank to offer services that didn't link to core banking systems, and nobody should expect that operators would do anything with NFV without strong OSS/BSS integration. That's the first attribute of a complete NFV solution. Operations efficiency and service agility demand this, whatever the specific NFV benefits you claim.
Just as you can't get to an operator's future without operations systems integration, you can't get to an NFV future without evolving out of legacy network infrastructure. Operators buy things that have anywhere from three to 30 years of expected life. If you launch NFV prudently, in controlled field trials, you get what one operator described to me as "making a rose garden by planting one rose in a poppy field." There's so much legacy stuff around NFV that it doesn't do anything that's even visible, much less compelling. That means any complete NFV solution has to spread operations and agility tools outward beyond NFV elements to the end-to-end network.
The final requirement is both simple and complicated. A complete NFV solution has to embrace every aspect of the virtualization trends sweeping tech. Virtual services, networks, software, resources -- everything. A complete NFV solution has to fully embrace software-defined networking (SDN), but not demand it be fork-lifted into being. It has to live in the cloud, in network-as-a-service, in software-defined-everything. The future's worth paying a price for if it's better than the present, which means different in important ways. NFV has to not only drive those differences, but harness and justify them.
Who are the full-solution players?
For all the hype around NFV, I've been able to identify only six vendors that can actually provide a complete NFV solution. Their strategies aren't exactly the same, but all can get the job done. If somebody thinks their company should be on this list, email me a full slide deck on your strategy with no NDA and a URL to validate its availability as a product, and I'll supplement this list in later blogs if I agree.
Alcatel-Lucent's CloudBand NFV takes a network-vendor slant on NFV, particularly focusing on mobile services and content delivery. These two specialties involve a lot of infrastructure and can justify a major deployment of servers and software tools, and so Alcatel-Lucent can build an NFV baseline for an operator that will then offer good economies of scale in follow-on services.
Ciena/Cyan's Blue Planet isn't focused on a specific service or service set. Instead they target issues -- legacy and operations integration and SDN support and the integration of multiple NFV domains or silos. You could start any NFV business case with Blue Planet, and you could use it to integrate silos created by past efforts too.
HP Enterprise OpenNFV has the most technically complete NFV solution, in my view. They have exceptional service modeling, the best I've been able to see complete documentation for. They also offer operations integration, support legacy devices as well as virtual ones, and they have all the platform products -- servers and software -- needed to deploy NFV.
Huawei has a strong SDN/NFV approach whose operations integration was proved with a TM Forum Catalyst demonstration recently. The political barriers to their use by operators in the US have made it difficult for Huawei to get full attention to their solution, which is fully developed and strong.
Oracle took advantage of the lack of operations and management meat in competing SDN/NFV positioning, and they've gained significant traction among operators who take a "top-down" or business transformation approach to next-gen networking.
Overture Networks has built their Ensemble family of NFV elements from open source components and has achieved as strong a functional solution to the requirements of NFV as any of the giants in this space. Because of its Carrier Ethernet roots, Overture's marketing focus has been virtual CPE, but it has much broader capability.
How could a community solution be created?
There are probably at least five times as many vendors that purport to have NFV solutions as those that actually provide enough to make a business case. This begs the question: Why isn't making a business case for NFV more of a community effort, and could such an effort now be started and hope to succeed? There are two approaches that might work: a community built around standards or open source, and a vendor/integrator coalition.
Logically, the ETSI Industry Specification Group (ISG) for NFV, the TM Forum, and open source bodies like OPNFV could form the nucleus of an open community solution. The problem is that none of the bodies named has the full scope of the NFV business case in their sights.
The ISG is focused on how to make virtual-function hosting and connection work, and not how to integrate it with operations and legacy parts of the network. The TM Forum addresses operations, but not so far the special issues of virtualization, and OPNFV has been tracking the specifications of the ISG rather than addressing a broader spectrum of requirements. While all this could change (and some certainly will), the changes won't help NFV in the near term.
That leaves us with the idea of ad hoc vendor communities, a hopeful concept on the face since it seems like every vendor is talking about an "ecosystem." There are in fact ecosystems built around all the major vendors and some others, but these build into the solutions of the main vendor. Most VNF providers, for example, are members of all the major NFV vendors' ecosystems. We don't see many examples of communities to create the core business value of NFV, for the logical reason that without standards to address all the issues and integrate the pieces, vendors have no technical framework to cooperate. Those who can address the issues and integration have no business reason to let others in.
My most recent operator survey suggests that the best opportunity for a "community solution" to NFV's business case is (surprisingly) to accept NFV silos and focus on using OSS/BSS orchestration to build services across them. Because none of the six full-solution vendors have promoted their capabilities effectively, operators have been forced to focus on small-scale trials that would naturally evolve to service-specific silos.
Will this OSS/BSS silo integration devalue a full NFV solution? That will depend on how effectively these six vendors present their strategies in the future, and on whether OSS/BSS vendors adopt the silo-linking orchestration model that would build an operations-dominated community. We'll likely see results in the first half of 2016.
— Tom Nolle, President/Founder/Principal Analyst, CIMI Corp., special to The New IP