HP ranks among, if not on top of, my selection of bona fide NFV providers. Their OpenNFV architecture is comprehensive in its support for operations integration and legacy device control, both of which are critical to making an early NFV business case. Now they’re taking on another issue, one that’s been raised in a number of places including recent LinkedIn comments on my blogs. The issue is VNF integration.
What HP has announced is HP NFV System, which is a kind of NFVI in a box/package approach. HP takes its own NFV Virtual Infrastructure Manager and server hardware that includes its carrier-grade OpenStack, pairs it with Wind River platform software and HP’s own resource management tools, and creates a handy resource bundle that can be packaged with VNFs to create either a complete service solution or a set of components that can build a variety of services. Or, of course, all of the above. The four “kits” that make up NFV System customize it for trial and standard missions and expand its capacity as needed.
Of course, NFV doesn’t need good strategies as much as it needs solutions to problems. The problem that NFV System may help solve is the orphaning of VNFs in the whole NFV onrush process. Everything about NFV is really about hosting VNFs and composing them into service, but some VNF providers and likely more prospective providers have a hard time figuring out how they engage at all.
VNFs, according to the ETSI model, run on NFV Infrastructure (NFVI). This in turn is represented to the rest of NFV through a Virtual Infrastructure Manager or VIM. Some of the latest models of NFV seem to want to make the VIM a part of MANO, which I disagree with. A VIM, and a superset of the VIM that ETSI is kind of dabbling around recognizing that we might call an Infrastructure Manager, are what resources look like to other elements of NFV. If you have an IM that recognizes your hardware then you have something that can be MANOed, so to speak.
That’s the principle NFV System is based on. It’s an NFVI atom that should plug into a standard NFV implementation because it’s a VIM with conforming technology underneath. That means that a software provider who wants to package their stuff for deployment could buy NFV System, add their VNFs, and sell the result.
This could invigorate the VNF space, which has so far been more posturing than substance. Without a VIM something that purports to be NFV-compatible is just hardware, and without a VIM to run through software functionality isn’t a VNF it’s simply a cloud application. HP has given voice, perhaps, to the VNF community at long last.
I say “perhaps” because we are still facing what IMHO is an imperfect management model for NFV and also an incomplete or inadequate model for how MANO talks to a VIM/IM.
The problem with the NFV management model is one I’ve blogged about before; here let me confine myself to saying that there is no explicit way that VNFs are pushed through the service lifecycle, there are some options. Even if those options are all workable (which I don’t believe to be the case), the problem is that there are multiple options and everyone won’t pick the same one. Right now a VNF provider would likely have to provide some integrated internal VNFMs packaged with their stuff. How those link to systemic management is still fuzzy.
The model problem is simpler to describe and as hard or harder to solve. Does a VIM represent only one model of deployment or connection? That would seem wasteful, but if there are several things a VIM can ask for it’s not entirely clear how it asks. There are examples of using YANG to describe service chains, OpenStack to host. But OpenStack Neutron recognizes a number of network models, so do we use that or use YANG or maybe something else entirely? Without a firm view of what MANO tells a VIM to do, how do we know that a given VIM (and the underlying NFVI) plug into a given MANO?
This isn’t HP’s problem to solve at the industry level, of course. HP’s OpenNFV has a broader VIM/IM model than ETSI defines, and a much broader set of options for integrating management and operations. Their NFV Systems would plug into their own OpenNFV software easily of course, and it would likely be at least more adaptable to a generic ETSI-compliant MANO than network functions off the shelf would be, given that there’s a VIM available. The ETSI process isn’t plug and play with respect to VNFs, though, and HP alone can’t force a repair.
This is a really interesting concept for a number of reasons, the obvious one being the empowerment of VNF providers. Some of the less obvious reasons may end up being the most compelling.
The first is that it highlights why VIMs need to be generalized to IMs and decisively made a part of NFVI and not part of MANO. Anyone should be able to create a seat at the table for their VNFs by providing a suitable VIM to deploy them and suitable NFVI to run them on. HP, by offering NFV System, may make it harder for the industry to dodge these points.
Next, we are significantly behind the eight-ball with respect to both how MANO describes a desired service to a VIM and how NFV and NFV-legacy hybrid services are managed. HP happens to have a good approach to both, and by making NFV System available they’re showing the world that there are sockets and plugs in NFV that just might not connect. Competition might induce ETSI or OPNFV to clean things up, or induce other vendors to respond with proprietary approaches. Either is better than a “wing and a prayer.”
Finally, this may well be the first example of somebody coming out with commercial NFV. This is a product, designed to support specific goals and to be used by specific prospective customers. It may not be needed in a lab trial or PoC, or even be critical in early field trials, but it does show that HP is taking NFV seriously. Given that an optimum NFV implementation would be the largest source of new data centers globally, that gives HP a big advantage in itself.
HP collaterally announced enhancements to HP’s Director orchestration product are making a good NFV strategy even better. It’s worth citing the release on this:
HP NFV Director 3.0 provides enhanced management and orchestration (MANO) capabilities that streamline bridging of NFV and telecommunications resources, as well as enable faster VNF on-boarding. It combines operations support systems (OSS) and IT management capabilities in a comprehensive, multi-vendor NFV orchestration solution that automate service and infrastructure management to enhance the flexibility and scalability of CSPs current OSS systems.
Bridging telecom and NFV resources means supporting both legacy and NFV-driven infrastructure, critical in making a transition to NFV and to supporting realistic future services that will always draw at least some services from traditional equipment. Faster VNF onboarding means getting functional value to operators faster. Combining OSS and IT management in a comprehensive multi-vendor orchestration solution is what efficient operations means. Director aligns HP even more with the critical early benefit drivers for NFV deployment.
I don’t have the details on all the latest Director stuff at this stage, but what’s out is impressive. It’s certainly something that other vendors need to be worrying about. Standards don’t seem likely to create NFV success, and a thoughtful blog by Patrick Lopez published HERE suggests that OPNFV may not be the magic formula for NFV success either. I suggested all last week that it might be time to let vendor innovation contribute the critical pieces that standards haven’t provided. Maybe HP is doing that, which could be good for the industry and very good for HP.
