Some time ago, the Linux Foundation in cooperation with the NFV ISG launched an initiative (Open Platform for NFV, or OPN) aimed at implementing the NFV specifications. OpenStack has now launched a “Team” that has the same goals. It’s not unusual for multiple groups to aim at the same target these days, both in standards and implementation, but when that happens you have to ask which effort is likely to bear fruit. It’s early in both processes but I’ll offer my views, organizing them by what I think are the primary issues in implementation.
NFV is really three pieces; the virtual network functions (VNFs) deployed to create service features, the NFV Infrastructure (NFVI) that serves as the platform for hosting/connection of the VNFs, and the management/orchestration (MANO) functions that do the deployment and management. The goal of all of this is to create a framework for deploying service logic in an agile way on a pool of virtualized resources. The NFV ISG’s approach is outlined in their end-to-end specification, which is where I think implementation problems start.
If you looked at the three pieces in a top-down way, you’d have to conclude that the first step should have been to define what you expected to be your source of VNFs. It’s been my contention from day one that the great majority of VNFs will have to come from existing open-source and proprietary software, the former largely running on Linux and the latter also adapted from embedded logic used by vendors. If we were to look at this pool of VNF candidates, we’d see that the stuff is already written and maps pretty well to what could be considered applications for the cloud.
Neither the Linux Foundation nor OpenStack seems to have started with the mandate that their strategy run existing logic with minimal modification and largely rely on current virtualization tools, but obviously there’s a greater chance that OpenStack would do that. OpenStack does seem to be taking things a bit more from the top, where the ONP activity is focusing initially on NFVI. So here, advantage OpenStack.
One of the specific problems that arises when you don’t consider the current applications as sources of VNF logic is that you define network requirements in terms that aren’t appropriate to the way the VNF source software is written. Here I think the ISG created its own problem with the notion of “forwarding graphs” as descriptions of pathways between VNFs. Anyone who has ever written software that communicates over IP networks knows that “pathways” aren’t a network-level feature. IP applications communicate via an IP address and port in most cases. The goal should be not to define the logical paths between components, but rather the network framework in which the components expect to run. If I have four components that expect to be inside the same subnet, I should create a subnet and then put them in it. Once that’s done, the way that they pass information among themselves is something I should neither know nor care about. IP is connectionless. But forwarding graphs encourage everyone to think in terms of creating tunnels, a step that’s unnecessary at best and at worst incompatible with the way the logic works.
OpenStack actually builds up cloud applications the way that NFV should expect, so it would be logical to assume that OpenStack will do this part right. The problem is that the forwarding graph stuff is in the spec, and the OpenStack team seems at least for now to be taking it seriously. Thus, here, we have to say that they’re starting wrong. ONP isn’t starting at all at this point, so we can’t call any win or even leading player yet.
The next issue is in the way that NFV relates to infrastructure. There are different virtualization and cloud options, different network technologies. If MANO descriptions of NFV deployments are specific to the hosting and network technologies—if they have detailed instructions appropriate to a single hosting approach or connection model—then every service would have to be drawn up in multiple ways reflecting all the infrastructure combinations it might use, and changed every time infrastructure changed. This, to me, cries out for a “double abstraction” model where a generic model for deployment or connection is abstracted to whatever infrastructure is selected. How that would be done in MANO isn’t clear in the spec in my view. OpenStack handles a low-level network abstraction because Neutron lets you map a generic model to connection tools via plugins. OpenStack’s orchestration model, now evolving as HEAT, has the potential to provide a tighter level of hardware integration with software deployment (DevOps). ONP, focused on NFVI, could address this stuff quickly by defining virtualization models for all resources, but it’s not happening yet. Advantage OpenStack.
There’s a related issue here, which I think is going to be critical. NFV isn’t going to be the total platform for many (if any) services; it will combine with elements of legacy infrastructure for access (Ethernet for example) and service connectivity (VPNs, for example). To deploy the NFV parts automatically while relying on different processes to deploy connecting legacy network elements seems to put any overall agility and operations efficiency benefits at risk. An effective double-level abstraction like the one I’ve suggested is needed for NFV elements in any case should be able to describe legacy provisioning, and so allow operators to build services with evolving mixtures of NFV and legacy elements. In my view, OpenStack’s Neutron has the potential to do some of this out of the box, and HEAT would add even more capabilities. Again, ONP has yet to address this issue as far as I can determine. Advantage OpenStack.
The final point deals with virtualization and management. The presumptive management model in the ISG E2E architecture is to expose infrastructure elements into the VNF’s “space” and also to compose “management VNFs” into virtual-function-based service features so that the features can be managed. This approach is workable in abstract but in my view it’s full of problems at scale. I think that you have to presume management views—both how VNF elements view infrastructure and how management systems view VNFs—have to be virtualized and composed in order to map evolving service elements to existing operations practices. Similarly, you have to be able to recompose your management views to accommodate the changes in operations you’ve made to gain agility and efficiency. I don’t see either of the two groups doing anything in this area, so there’s no way to call a winner.
So where does this leave us? I think there are a couple of areas in NFV implementation where the OpenStack people have an obvious lead. I don’t think there’s any area where I can say that ONP has the upper hand, at least not yet. Despite the fact that OpenStack’s NFV Team is a kind of new kid, I think it may be the most likely forum for the development of a logical NFV implementation. However, as I’ve pointed out here, there are some issues that if not addressed will IMHO lead to crippling flaws in the implementation. These will undermine the NFV business case, or force operators to adopt vendor-driven solutions that are more comprehensive. It may well be that neither of these open implementation initiatives will succeed, in which case there is likely no hope for any standard implementation other than a de facto vendor solution.