The OPNFV project released its first (“Arno”) build, and it may be more noteworthy for how the pieces it contains were selected than for its functionality. There’s logic to how OPNFV did its work, but there are also risks that its order and timing of releases pose.
Arno is a platform that includes the infrastructure (Network Functions Virtualization Infrastructure or NFVI) and the Virtual Infrastructure Manager (VIM) components of the ETSI ISG’s E2E model. The combination offers the ability to deploy and connect VNFs in a cloud architecture based on OpenStack and OpenDaylight. The features are based on the ETSI ISG’s Phase 1 work, and the model does not include orchestration or management (MANO, VNFM).
OPNFV is, as a group, in a challenging position. Open source development is often done from the bottom up, simply because it’s hard to test something that sits on top of the functional stack and looks downward into nothing but vague specifications. If the software design is done top-down, which I’d contend is the normal practice for the software industry, the bottom-up development doesn’t pose any major risks.
In the case of NFV, the problem is that ETSI’s work was also bottom-up. The understandable desire to complete a model of the technical core of NFV—deployment and management of virtual functions—led the body to limit its scope, excluding things like control of legacy elements, end-to-end service management, operations integration, and federation of elements to/from other providers or partners. Some of these may be addressed in Phase 2, but all of them create requirements that probably could be more easily addressed by being considered up front, before the high-level architecture of NFV was laid out.
OPNFV has a commitment to tie its activities to the work of the ISG, which means that the development will also have to contend with these issues as it evolves. That might involve either making significant changes to achieve optimal integration of the features/capabilities, or compromising implementation efficiency and flexibility by shoehorning the capabilities in.
One interesting aspect of the OPNFV Arno release that demonstrates this tension is that Arno includes NFVI and VIM, which in my view implies that the two go together. In the ETSI E2E model, though, VIMs are part of MANO, which is otherwise not represented in Arno. I’ve argued that VIMs should have been considered to be part of NFVI from the first because a VIM is essentially the agent that transforms between an abstract model of a deployment/connection and the realization of that abstraction on actual resources.
The good news here is that OPNFV may be quietly rectifying a wrong here, and that this may be an indication it will continue to do that. The bad news is that it’s a wrong that should never have crept in, and that significant divergence from the ISG specification as we evolve OPNFV begs the kind of disorder that creeps into development project that don’t have a firm spec to begin with.
Let’s go with the good first. In the real world, infrastructure for NFV is totally abstracted, meaning that a VIM proxies for all of the stuff it can deploy/connect on or with. This seems to be the approach OPNFV takes, but if that’s so then one thing I’d like to see is how multiple VIM/NFVI plugins would actually work and be connected with MANO.
If there are multiple VIM-plugins, then MANO presumably has to be given a specific plugin to use in a specific situation, meaning that MANO models would have to have selective decomposition so you could pick the right plugin. If MANO doesn’t do that, then there has to be some sort of generic plugin that further decomposes requests into the individual infrastructure-specific plugins needed depending on configuration, service parameters, etc. I’m not aware of either of these capabilities in the current MANO model.
Then there’s management. If a VIM carries infrastructure upward into orchestration, management needs to know how that carrying chain is handled so that resources actually involved in a service can be associated with the service. I don’t know how that’s supposed to work either.
Finally there’s federation. If I have a VIM representing resources, why not have a VIM represent federated resources? Does the current approach have the necessary hooks to be used across organizational boundaries? Don’t know. So to summarize, we have a lot of potential for good here but not enough information to realize it fully.
On the bad side, the challenge is both that we may have insufficient specifications to back up development, and that we may have too many. The ETSI ISG, for example has tended to look at service and resource data in an explicit sense, like most of the TMF SID applications do. You need a field called “maximum instances per load-balancer” so you define it. The problem with that is that you end up with a billion or so fields most of which are irrelevant to a given service, and every new service or feature is likely to spawn a chain of new fields. What developers would do is simply to declare variable attributes, in an XML-like way, and say that any “field” is fine as long as something fills it and something else uses it. No need for names or pre-defining.
So what does the OPNFV group do about this? Do they do the right kind of development or follow the ETSI model explicitly? Right now we don’t have the answer because nobody has really defined what the northbound interface of a VIM should look like in detail. In both my NFV projects (CloudNFV and now ExperiaSphere) I modeled this stuff as either XML (or a derivative) or TOSCA and presumed a structure that defined an “abstraction-type” and then type-dependent details. I’d like to see somebody say what the ISG/OPNFV presumption is.
NFV has a way to go before it defines all the functions and features needed to make its own benefit case. Where OPNFV could help is to address the places where that benefit connection is anemic. But if the body wants to stay “technical” then the key point to look at would be the abstractions that define service models and that should define the interface between VIMs or other “infrastructure managers” and MANO. You are, service-wise, what you orchestrate, and you orchestrate what you model.
The big challenge for OPNFV remains time. Operators need something by the critical 2017 revenue/cost crossover, and markets are advancing with per-vendor solutions whose scope matches benefit needs, in part because nobody has a sanctioned open approach that does. At some point, further work will get so far behind the state of the market it will be too late to influence things.
