Those of you who follow me on LinkedIn may have caught my creation of a LinkedIn Group called “CloudNFV”. Even though the group is currently invitation-only I’ve received many requests for membership, and a select few found the CloudNFV website and figured out a bit of what was going on. Craig Matsumoto of SDNCentral was one of that group, and he called me recently for comment. We’re not opened up yet, but I did tell Craig some things (see his article at http://www.sdncentral.com/news/nfv-stealth-group-working-on-a-prototype/2013/07/) and I want to introduce my activity to those who follow my blog.
This all started because, by background, I’m a software architect and director of software development. I’m far from being a modern, functioning, programmer but I’ve still kept my hand in the process and I understand successful network projects because I’ve run them. I’ve also been a member of multiple network standards activities, and one thing I learned from the combination is that traditional international standards activities don’t do software.
When Network Functions Virtualization kicked off last fall, I emailed all the operators on the white paper list and offered a recommendation—prototype this thing as quickly as possible to minimize the risk that the standard will turn out not to be a useful guide for an implementation. I also suggested that the body forget the notion of designing NFV to be capable of running on everything from bare metal to the cloud, and adopt the presumption of cloud implementation. That would simplify the process of specifying how functions could be deployed and operationalized, and take advantage of the enormous body of work cloud computing has produced.
In the early spring of this year, I had an email and phone exchange with the CEO of a highly innovative software company, and I saw their stuff as a logical element in implementing an NFV prototype. The CEO agreed and attended the April NFV meeting. At that meeting I made a number of suggestions about implementation, and my comments generated quite a bit of discussion in the parking lot during the breaks. From the dozens who stopped by and chatted, there were a small number who stayed. These were the very kind of companies whose contributions would complete an NFV implementation, companies who represented the best technology available in each of their areas. They agreed to work together as a group, and CloudNFV was born.
There are three foundation beliefs that have shaped our activity since that parking-lot meeting. One was that we needed an NFV prototype to create a software framework that would pull NFV out of a standard and into networks. Another was that the cloud was the right way to do NFV because it’s the right way to do computing. The last one was that as cloud computing converged more on SaaS, cloud providers would converge on the deployment needs and operations needs that were shaping NFV requirements. There is, there can be, only one cloud, and NFV can define how both applications and services deploy on it.
So we’re doing that “supercloud” deployment and operationalization, following the model of NFV work but framing it in terms of the three guiding beliefs. We’ve combined the elements needed for optimized hosting of network functions on computers with tools to gather network intelligence, a highly innovative virtual-networking model that recognizes the multidimensional nature of SDN, and a powerful unified knowledge framework that manages everything about functions, applications, resources, services, and policies as a single glorious whole. And none of this is from giant network vendors; none of the group fall into that category. We’re not a startup trying to be flipped, we’re a community of like-minded people. Some of us are small in size and some are IT giants, but all are thought leaders, and all are working toward a strategy that will be effective, open, and extensible.
And we will be open, too. When we’re ready to announce public demonstrations we’ll also announce when we’ll publish our data models and interfaces, and we’ll describe how we’ll be able to expand the scope of our prototype to include other software and hardware. We’re not going to offer to integrate the world at our own expense, but we will cooperate with others willing to expend some of their own resources to link to our process. We’re hosting in one of our member’s labs now, but our approach can support federation naturally so we’re happy to install in operator labs anywhere in the world and run as a global ecosystem. Nobody is going to be shut out who really wants to participate openly and fairly. We’re not sanctioned by the NFV ISG, but we do insist that those who want to join also join that activity. It’s not expensive, and you can’t be committed to NFV without being committed to the international process that’s defining it. We are, and we’re committed to making it work for the network of today and for the cloud of tomorrow.
If you want to participate in CloudNFV when it opens up, I’ll ask you to send a Join request to the CloudNFV LinkedIn group if possible, and if not to send me an email directly. You can review all the information we’ve made public (including a link to this blog and Craig’s article) on the CloudNFV website (http://www.cloudnfv.com/). I’ll update the site as we add information, and this site will be the repository for our public documents as they’re released.
When? We will be scheduling selected carrier demonstrations in early September and we’ll likely be doing public demonstrations by mid-October. Somewhere between we’ll begin to publish more information, and we expect to be able to show an NFV deployment of IMS with a basic TMF Frameworx integration and full operational support including performance/availability scale-up and scale-down, by the end of this year. You’ll see then why I say that CloudNFV is as much “cloud” as it is “NFV”. Well before then we’ll be starting to work with others, and I hope you’ll let me know if you’re interested in being one of them.