I’ve blogged before about HP’s OpenNFV strategy, important IMHO because it’s not only from perhaps the most inherently credible of all possible NFV sources but also the functionally most complete—at least in terms of planned features. I’ve attended the HP Discover 2014 event in Barcelona this week, spoken to all the key HP NFV people, and I have a better understanding of OpenNFV than before. I’d like to share it with you, and also take a moment to thank all of you who came up to me at various points to say they’d enjoyed my blog. It’s great to get two-way feedback, and much appreciated!
I think what sets HP apart from the first is the fact that the company has its head in the clouds, NFV-wise. The head of the HP NFV program is Saar Gillai, also SVP/COO of HP Cloud, and everyone involved in OpenNFV knows that it’s an application of cloud principles to the hosting of network functions. You all know that from the first I’ve said that the cloud has to be the root and heart of NFV, and HP clearly believes that.
At a high level, OpenNFV is a cloud project, an open initiative designed to build an ecosystem in the very same way you’d expect a cloud activity to work. HP proposes to provide a platform, roughly corresponding to the ETSI NFV framework at one level but extending it as well. This platform is then a host to partners who extend its functionality in two primary directions—the VNFs and NFVI.
HP has a strong belief that VNFs have to be open, meaning that an NFV platform can’t be tuned to support only its own vendor’s VNFs and thus create a kind of NFV silo. They’re signing up partners to contribute VNFs and VNF management tools, tools that don’t require that the VNF code be customized to be on-boarded. Given that you don’t get much business value from NFV without virtual functions, that’s an important step.
In the world of NFV Infrastructure, HP’s partners bring deployment and management tools that broaden what VNFs can be run on. An example I found particularly interesting was Genband’s “Metal-as-a-Service” concept. This creates a deployment framework for VNFs that can deploy on VMs but also on dedicated servers. In either case, the same horizontal scaling and adaptive replacement of hosts is provided. This is smart because, as I’ve pointed out before, many proposed applications of NFV are already multi-tenant in nature and would normally not run in a VM at all. IMS and perhaps parts of EPC come to mind.
The NFVI dimension is also interesting, because HP itself also extends the NFVI piece, and in perhaps the most critical dimension—to legacy network infrastructure.
The OpenNFV Director, which is HP’s orchestrator and management framework, sprung from work HP did in the OSS/BSS space, to extend service activation functionality to the control of legacy network devices. Because Director inherited this capability, HP is providing what is in effect a parallel “Infrastructure Manager” to the “Virtual Infrastructure Manager” mandated by ETSI.
IM/VIM elements are critical to NFV because they’re the link between service logic models and infrastructure, the boundary between what I’ve called “functional” and “structural” orchestration. With HP’s approach, service functions exposed by networks can take the form of hosted functionality (deployed through OpenStack, in the HP model) or embedded features of legacy devices and networks accessed through NMS APIs.
The reason that this legacy integration is critical was exposed in a number of the panel sessions on the NFV track of the conference. The issue in a nutshell is that NFV’s most credible benefits—operations efficiency improvements and service agility enhancements to advance operators into new service areas for revenue augmentation—are inherently ecosystemic in nature. You can’t make part of a service efficient or agile and gain the full benefits you’re targeting. In fact, since NFV is likely to initially roll out over a small piece of the total infrastructure pie, you may not even see any local benefits to NFV in these areas until the deployment of NFV is well along. That begs the question of how you prove the benefits of NFV in those early “not-enough-to-notice” phases to justify that larger roll-out in the first place.
I’ve pointed out that in my own surveys operators were unanimous in their view that they could not at this point make an NFV business case, nor could they see how any of their current PoCs would allow them to do that. A Current Analysis survey showed similar results; on a scale where 5.0 is “full agreement”, “Concerned about NFV ROI” ranked about 4.4 with operators.
The net result of the HP extension of VIM to IM is that you can apply the OpenNFV Director to all of the network, not just the NFV part. That would mean that operators can immediately spread the service automation that NFV demands to the whole of a service. It also means that you could in theory “orchestrate” networks that had no NFV at all.
I’ve blogged before that MANO principles were so important to networking as it is today that they’d arguably create a massive benefit even if NFV deployment never happened. That’s still true, but the goal would not be to eliminate NFV but to support an on-ramp to NFV’s benefit expressway.
Let’s say an operator plans to offer enhanced higher-layer services to augment their revenue stream in Carrier Ethernet. They would normally sell users a box or boxes to provide edge functions like NAT, VPN on-ramp, firewall, virus scanning, and even extended management of site networks or facilities management and control. With the OpenNFV approach, this operator could roll out the service using legacy facilities where they are in place or convenient, but immediately manage them using the automated processes that NFV would normally provide. This early “native box” deployment could evolve to a distributed edge-hosted version of NFV where VNFs are loaded as needed into CPE. That could in turn give way to VNFs hosted in the cloud.
This progression would let operators set operating practices and tools immediately and uniformly for an evolving set of service resources, deploying NFV where and when it’s most valuable. That contains operations impact in the early stages, reduces first costs, and eliminates the need to strand assets to achieve homogeneous infrastructure to unify operating practices and secure optimum opex benefits.
All of this demands robust service modeling, and in a number of panel discussions and conversations HP articulated its commitment to that functional/structural modeling process. At the functional level, a level most NFV vendors still won’t accept, HP proposes to use a flexible XML framework to describe services and their management connections. This would create a hierarchy of service elements similar to that which the TMF defined in their notion of “customer-and resource-facing” services. The “customer-facing” part would be functionally modeled, and those models decomposed on deployment to map to structurally orchestrated deployments—either of legacy network features or VNFs.
HP believes that a central management tool beats having management deployed ad hoc by including it in or binding it with VNFs. I agree, but I’d like to convince them that this central tool should be logically central but physically distributed—linked to the service data model as a state/event-activated process set. I’d also like to see them evolve from their initial position of presenting VNF features as virtual devices to make them compatible with legacy management. The end-game in my view is where both legacy and VNF-based functionality is virtualized and presented in all the forms needed by the operator or service user.
HP is serious about this, and so are their partners. I attended a partner reception, met a lot of you readers of my blog there, and observed and took part in a lot of NFV discussion. This at a museum location with a stunning view of Barcelona and an overall ambience that hardly encouraged technical discourse. Yet these partners were talking NFV—all the aspects from technology to deployment models and business cases. There were so many interesting discussions that I couldn’t even listen to half. It’s engagement here, engagement of the truly committed.
If you look into any NFV deployment, no matter who provides the technology, you’re not going to see a network, you’ll see a cloud. But if you look at NFV even in mature installations, you’re going to see it as part of a network. HP has harmonized these critically different perspectives, and by accommodating both created a credible pathway to getting NFV out of the lab and into the business. So far they’re the only vendor who can say that.