I just had a chance to read the Light Reading story on NFV (“Down But Not Out”) and it’s a nice summary of the NFV situation. It also documents my own frustration with the issues, because while everything the article says is true, every issue that the article presents was well-known in 2013. I know that because I produced the first approved ETSI NFV Proof of Concept, called CloudNFV, and in the PoC document I described all the things that needed to be done, and what steps we’d already taken within the project to do them. We need to look at the question of how things got off-track, because future initiatives are at risk for the same problems.
When the “Call for Action” paper that launched NFV came out in the fall of 2012, it proposed the substitution of hosted functions on commercial servers for proprietary appliances. This seemed to me to be a straightforward cloud mission, and I sent the operators who produced the paper a set of comments pointing to that issue. In the paper I noted that the goals of NFV had to be harmonized with the direction already being taken in the cloud, and emphasizing that we needed to develop a kind of “Platform-as-a-Service” middleware toolkit to organize NFV components, but most of all the Virtual Network Functions (VNFs) into something that could be open and would harmonize differences in implementation. It was critical, I said, to approach NFV as a top-down process, defining the high-level relationships and goals, turning them into features, and then defining implementations and data/interface models.
In March of 2013, I provided the newly formed ISG a slide presentation that outlined the specific issues I believed had to be dealt with. In that presentation, I proposed that NFV be “positioned as a cloud application set” that drew on cloud capabilities for resource management and deployment, what today is called a “cloud-native” model. I also stated again that is was critical not to create so much complexity in building services that operations cost increases overran capital cost reductions.
From the very first meeting of the ETSI NFV ISG in the US in the spring of 2013, it was clear that there were two problems. One was that the NFV process was proceeding from the bottom up, meaning that the ISG was defining low-level functional elements without having established the requirements framework to justify them. That risks creating an implementation that doesn’t solve the critical problems of the new technology, because the problems weren’t defined. The second was that to contain the time needed to complete work, the ISG elected to declare the operations processes of NFV out-of-scope. That meant that the body would not propose a specific means of managing a service lifecycle, which means one could not be guaranteed to emerge.
This presentation contained a slide titled “Mapping Cloud Resource Control to NFV” and it suggested that everything in the scope of NFV could be addressed either by cloud infrastructure tools (VMs, containers, and multi-tenant web-service-like tools) or by cloud DevOps tools. In other words, all the ISG really needed to do was lay out an object model for NFV and map that to current cloud technology.
I spoke up frequently at that meeting, objecting to these and other points, and it was during a break at the meeting that the group of vendors who formed the CloudNFV initiative collected and agreed to cooperate on an implementation. I laid out a model based on my previous contributions and on work I’d done in my ExperiaSphere project, whose first phase was a Java implementation of the TMF’s Service Delivery Framework (SDF), an early orchestration initiative. It was the CloudNFV team that generated the PoC submission I cited above.
I’d invite everyone who thinks that NFV has fallen short of its goals to read that document, because it shows that the goals we now recognize were understood and accepted by some operators and vendors even then. The project defined in that PoC addressed many of the issues and framed a process to explore the details of others, with the goal of defining the right approach and then implementing it. I think that if this project had been fully supported by the ISG and had run to its completion as planned, it would have created a totally open platform that fulfilled the goals of the original white paper, and more.
One of the precepts of CloudNFV was open-source VNFs. The PoC was based on that; Metaswitch’s Project Clearwater implementation of an open-source IMS. There was no question that without competition from open-source tools, commercial sources of VNFs would likely impose licensing fees high enough to contaminate the benefits of NFV deployment. They did. Another precept was service lifecycle management based on a data-model hierarchy. There was no question that without this, realistic operations practices and costs could not be attained and sustained. They weren’t.
I suggested to NFV ISG leadership that the entire NFV operator community join as sponsors to the project, to put their weight behind the concepts that operators seemed to agree were essential to NFV’s success. This wasn’t to promote myself; I was working unpaid on CloudNFV, as I’d promised to do for the first year. Only two operators stepped up as sponsors, which wasn’t enough to generate momentum for a complete NFV solution. Without full support, the PoC testing tool time, and eventually it passed the one-year period in which I’d promised everyone I could supply my time at no cost. When I withdrew from the project early in 2014, the scope of the PoC was drastically cut back and the goals of the original PoC were never realized.
Even a couple years into the initiative, there was hope for an open-source-centric vision of VNFs. In a blog I did in 2016 I outlined a pathway to creating more open-source VNFs and improving the competitive environment. I also authored an extension of the ExperiaSphere project that gave rise to CloudNFV, and developed a whole series of presentations describing an open implementation with open VNFs and management orchestration, based on the TOSCA model.
I agree with the points made in the Light Reading article. NFV is down but not out. However, I think that “not out” doesn’t necessarily mean NFV will eventually fulfill all its promises. Too much time has been spent doing what wasn’t needed, or even useful, and too little addressing the fundamental points that had to be made to work if NFV were to meet any respectable business case. If the ISG is serious about an extension of its mandate by ETSI, then defining the right approach, even if it means backing off from some of the things already done (always hard in a standards process), is the thing that additional time should be focused on.
CloudNFV was an open process. At the time of the PoC there were 9 vendors formally involved and another vendor’s tools (Red Hat’s) were used in deployment. There were only six founding members. We had also launched an initiative, including documentation, to recruit other members and integrate new features, including test and measurement and support for multi-tenant VNFs (like IMS and EPC in mobile networks, and like those used in content and ad delivery). It could have been exploited widely, evolved into an early and open implementation that could then evolve to meet market requirements as they were exposed by ongoing dialog and testing.
There was no need to fall short with NFV. The basic concept was sound, but the realization of that concept fell short because it didn’t reflect good software or good business practices. It can still be fixed, but the fixing would have to step back from many of the details that have been added in the last four years, and rely more on outside tools and practices.
It’s not easy to say that the wrong thing has been done, and to go back and fix it. Hard or not, that’s what’s going to have to happen if NFV is to achieve all it could achieve. But I need to make an important point here, which is that time marches on. In the four wasted years of NFV, when it left what should have been its cloud roots to duplicate a lot of cloud initiatives, its opportunity to drive carrier cloud has largely passed, and even a completely compliant and fully effective NFV spec couldn’t turn back the clock now. We now need, even more, to think of NFV as nothing but a cloud application, because carrier cloud is going to drive whatever NFV deployment there is, not the other way around.