One of the issues I’ve gotten concerned about regarding NFV is the openness of a vendor’s NFV architecture. The NFV ISG clearly intends to have a high level of interoperability across NFV elements and solutions, but there are some factors that are hampering a realization of that goal. Most of these aren’t being discussed, so we may be on track for some NFV grief down the line.
The first issue is incomplete implementation of NFV despite claims of support. There are three elements to NFV according to the specifications; the MANO or management/orchestration core, the virtual network functions (VNFs) themselves, and the NFV infrastructure (NFVI). According to my rough count, less than 10% of NFV implementation claims even represent all three functional areas. It’s not necessary to actually offer everything, but what I think a vendor has to do is express where each of the three pieces are expected to come from and how they’re integrated with their own stuff.
The biggest NFV offenses come from vendors who provide NFVI or VNFs and call it “NFV”. Virtually anything could be claimed to be part of NFV infrastructure. For servers and platforms, all you really need to do is be able to run a VNF, after all. For network connectivity, you need to be able to support SDN or some form of explicit virtual network provisioning. The question is whether an “NFVI” vendor offers a handler that exposes a logical abstraction of their infrastructure. NFVI credibility depends on that.
The second issue in openness is supersetting of the VNF-to-MANO interfaces. I am not a fan of the idea that VNFs even talk directly with MANO, simply because there’s no MANO today to talk with and thus no current code that can call on MANO services could be available. That implies everything has to be rewritten for NFV. However, even if we’re willing to do that, it’s already clear that vendors are going to define their own “platform services” for VNFs that are not called for or specified in the NFV documents. That means that a given vendor’s VNFs could pull their MANO through because nobody else could support its extended VNF-to-MANO interfaces.
Every NFV implementation has to start with something, and that means that there will be a limited number of VNFs to be used. If those VNFs can create a kind of walled garden by their relationship with proprietary extensions of the NFV specification for VNF-to-MANO connections, then every new service might end up pulling in its own MANO, and any hope of securing efficient operations is lost.
The third issue in openness is that of management integration. The NFV ISG presumes that there will be a management element integrated with the VNFs, and that this element will then expose management interfaces and capabilities. There are several issues with this approach, IMHO, but the “openness” problem with that is that the way by which VNF managers manage the subordinate VNFs isn’t standardized. A management system could be pulled into an NFV deployment by the customized management approach a vendor offers, then that management system could pull in the vendor’s other VNFs and even NFVI.
Of the specific problems we face in NFV openness, two stand out. One is the challenge of abstract infrastructure. The ideal option for NFV would be to have a set of “models” that define both hosting of virtual functions and network-building, in such a way that any server and network platform (respectively) could be harnessed to implement the model. That includes all the current network devices and EMS/NMS service creation interfaces. I’ve yet to see a truly compliant standard approach to this kind of definition; OpenStack’s Nova and Neutron come close, but that’s all.
The specific issue is the management side. Here we have to deal with a couple of new wrinkles in modern virtualization-based services. One is that any “virtual” or “abstract” service is presented to higher layers as an abstraction, and abstractions have to be managed as what they look like and not just by managing the subordinate elements. A buyer who gets a virtual branch access device needs that virtual device to look like the real thing, yet the NOC that supports it has to see the components. This kind of management dualism is critical. The second wrinkle is that unless we have an accepted standard for higher-level orchestration—one that recognizes all the elements of the service end-to-end, we can’t cede management tasks into MANO. Doing so would mean that an implementation of MANO would have to rely on non-standard mechanisms to present management views and parse a tree of service structure from the user level down to the resource level. That’s the end of openness.
This raises what might well be the most critical question for NFV openness, which unfortunately may not have anything to do with NFV per se. NFV is about virtual functions, yet it’s likely that no future service will have more than about a third of its functionality virtualized. We’ll still be using traditional VPNs to provide connectivity to all those virtual branch access devices. NFV’s MANO is not directed at solving the management/orchestration problems for these complex services. Nothing else is either, at the moment. So the question is whether we can define how part of a service is managed/orchestrated without knowing the big management/orchestration picture into which it must fit.
Some analyst firms have indicated that NFV field trials will start this year, and they’re right. Many say that no real deployments will happen this year, and they’re sort-of-wrong there. There will be deployments that vendors and even operators will represent as being “NFV”. Those deployments will be almost totally lacking in the essential elements of an open strategy. Part of that is because the ISG specifications for NFV are not complete so they can’t be complied with yet. A bigger part is that most vendors don’t want open NFV, they want an NFV solution that only they can supply. That kind of opportunism is to be expected in a profit-driven world, but that doesn’t mean we have to turn a blind eye to it. If operators want an open NFV approach, it’s going to be up to them to force the issue—or more directly force the resolution of the issues I’ve exposed here.