The Open Platform for NFV initiative appears to be getting up steam, with the support of vendors and network operators alike. I’m a long-standing fan of open-source software and a specific advocate of it in the NFV space (see my ExperiaSphere project), but while there are some hopeful signs in OPNFV so far I’m still concerned about the direction the project will take and the good that can come of it. To get to the questions and concerns, we need to start off with the OPNFV activity in brief.
OPNFV operates under the Linux Foundation, and it’s an open-source project rather than an alternative to the ETSI NFV ISG. In fact, the goal of the project is to support and implement the ETSI specification. Like other open projects (OpenDaylight for example), it has both code contributors and member companies, and the latter pay fees. Participation outside these two categories doesn’t appear to be in the cards, which means that interested parties who don’t write code or can’t spend the member fees can influence OPNFV only via the ETSI ISG, which still permits free memberships.
The white paper on OPNFV, and the overview of the project on the website, frame the goals in terms of the ETSI E2E architecture, and specifically the combination of the NFV Infrastructure and Virtual Infrastructure Managers (NFVI and VIMs, respectively). From here, the project will presumably move to address the other blocks of the E2E document, eventually filling in all of the blocks. Some of the work will presumably be new development and other parts will exploit other projects, including OpenStack, Linux, DPDK, etc.
The first question that comes to mind relating to OPNFV is simple; is the ETSI NFV E2E specification enough to drive an open-source project? As someone who was a software architect and engineer in a prior life, I’ve been honest from the very first in my concerns about one aspect of the work—it didn’t follow the traditional “top-down” approach of software projects. I said from the outset that if you want to define something that’s going to be software, you have to do the job as a software project.
The purpose of NFV software is to run virtual functions, logically speaking. That means that you need to decide where the virtual function software is expected to come from and what “services” you’d provide that software when it runs. That wasn’t done with the ISG, and the OPNFV doesn’t propose to start with the VNFs either. Thus, I can’t be sure that the most basic question—what does the NFV software do to run VNFs—can be answered.
NFVI and the VIMs are at the bottom of the process. What they have to do is support the things above, and so starting off by defining them and developing or identifying code creates a risk that you’re building the foundation without knowing if this is a single-family ranch or a skyscraper. And you could make the same comment regarding the management interfaces. How can you decide how to manage resources without knowing how resource management relates to virtual function management?
There is a missing piece in the puzzle here, an important one. What you need to do software is a software architecture, which the ETSI process never professed to be building. An architecture links the goals, the high-level drivers of benefits, to the processes and relationships needed to fulfill them. And if you do an architecture right, you do it in an open way so that it doesn’t constrain your avenues of approach and execution. An open architecture is platform-independent, it admits both open-source and proprietary solutions. We need an architecture for NFV, and that’s a basic truth.
The second question relates to what we did get, which is the specific interfaces. Interface specifications help create open solutions, but they should be built on the architecture that links benefits to functions. OPNFV is, according to its white paper, proposing to address the implementation of NFV by implementing the interfaces, but the lack of a unifying software architecture means the interfaces may not be sufficient. We should think of infrastructure, the first goal of OPNFV, as a collection of resources available to an Orchestrator to build a service. This implies that the resources are represented as a set of abstractions that can be mapped to a set of platforms and tools. Where are these abstractions? What features of infrastructure, whether virtual elements or behaviors of real network devices, are needed to represent services? That would have been a fundamental element in any formal software architecture, but just implementing interfaces won’t provide these critical pieces. Where would the notion of virtualization be today if we never had the notion of a “virtual machine?”
There’s also a lower-level question here. If you want to support multiple cloud architectures (OpenStack, CloudStack) and if you want to support multiple hardware platforms and operating systems, you have to assume that the interface between the VIM and the NFVI elements is variable depending on what’s down in the NFVI. How then do you define the Nf-Vi Interface, which is the one used for the VIM-to-NFVI connection? The fact is that the interface to the VIM could be based on standard abstractions, but the interface between the VIM and the NFVI has to speak the language of the underlying elements or you have to rewrite what’s already availablew.
Finally, we have the third question, which is how long will this take? OpenStack, OpenDaylight, have been going on for some time and yet they’re still in an early phase. Is it possible that we’re defining an open-source platform that won’t be ready in time to make NFV an effective tool in managing carrier migration to software-and-server functionality? Is it possible that we’ll see “member wars” within OPNFV just as we’ve seen them in other bodies, wars created when sponsors try to get the project aligned with their own interest? Might some even be accused of becoming involved just to obstruct?
I’m not saying all of this will be an insurmountable problem, or even a problem at all. I am saying that we don’t know at this point whether OPNFV will insure these questions don’t become problems because the nature of what they’ll produce and how they’ll work isn’t yet clear. And my final point, time, is marching on.
So here’s my conclusion. The ISG process should have taken a top-down approach. The OPNFV process, by accepting the ISG model in the first place and then starting at the bottom of that model, is hardly likely to reorient all of NFV toward that optimal top-down model. However, spec work is all theory and any implementation approach is a positive step toward solidifying the issues associated with real NFV software. That means that at the very least we’re likely to learn a lot from the OPNFV work. I just hope we won’t pay too much of a price along the way.