The term “-washing” is applied all too often in our industry, where the dash is preceded by the name of some hot technology like “cloud”, “SDN”, or “NFV”. Everyone loves publicity and if you can get it by simply tattooing the name of some hot concept on your forehead, so much the better. Of course, at some point, buyers will have to separate the thin veneer of something to the full substance, because nobody ever built a network or an IT plan from a tattoo.
NFV is perhaps especially susceptible to washing. The specs aren’t done, the concept spreads out a lot across both the IT and network space, and use cases suggested to expose issues rather than to define total solutions can be addressed without actually solving the overall problem that the NFV ISG has dedicated itself to solving. Then there’s the fact that NFV will have an impact on things like operations and inter-provider federation that may be fully or partly out-of-scope to the work of the ISG. Operators reported in our fall survey that vendors were not providing them complete NFV solutions in their PoCs and even in RFI responses, but those vendors are sure happy to stick an NFV bumper-sticker on their bandwagons. What’s a buyer to do?
The emergence of multiple NFV Proof-of-Concepts in the ETSI ISG could be a help to buyers in the long term, but for now the submitted proposals don’t all aim at the same goals or even cover the same implementation ground. Thus, even when reviewing PoCs, it’s important to apply some kind of structured process. Well, one possibility is to look for specific things in an NFV claim, things that will separate the real from the wash, and this is what I want to talk about. I propose a list of seven things to ask anyone who says they have NFV.
The first thing on the list is can you provide me with a list of the specific contributions your company has made to the NFV ISG, including applications for and approvals of Proof-of-Concept? How can somebody be implementing NFV if they’re not a contributing member of the NFV ISG? There is no significant financial commitment needed to join the ISG, so there is simply no excuse for non-member status. Any member can contribute, and if you’ve done enough to say you have any or all of NFV implemented you should be able to point to your contributions to the process.
The second thing is where do your virtual functions come from? There are three possible answers here: from any source, from my own developer program, or from “standard” sources. Obviously the second answer means virtual functions are proprietary; they’ll work only for the NFV implementation they’re developed for. That’s not a very good match to open commercial servers for deployment, and yet the operators tell me that vendor responses to RFP/RFIs issued so far tilt overwhelmingly toward proprietary virtual functions. If standard APIs are needed, the question is whose standard they follow. The ISG hasn’t defined any yet. The best answer here is “from anywhere”, which means that open-source code currently available and third-party development from almost any source would be suitable. But those who claim this should be able to explain how the virtual functions’ interfaces (including management interfaces) are connected at deployment time.
Point number three is how do you accommodate different hosting platforms? Ideally, an NFV implementation should be able to deploy a virtual function in a VM, on bare metal, in the cloud, on a board in a network device, or even on a chip. There would clearly have to be customization for the specific environment, but that should be handled via a modular plug-in or something. Demand openness here because if you don’t you’ll end up with a single-vendor NFV solution, which has to be anachronistic at the least.
Point number four is related; how to you drive connections, among VNFs and with other legacy elements and endpoints? The biggest single failing of NFV strategies is that they are intra-function in their connection support. Do you think your service chains will live independently in the great beyond, chugging away and presumably getting billed to your customers without being connected to their VPN or access links? Probably not, but if you don’t have an NFV networking approach that can connect all kinds of legacy and NFV resources together, you can’t support transitional environments or uniform deployment practices.
Point five is how does management of virtual functions work, both within the NFV part of a service and overall? There are really only two choices here; what I’ll call “simple” management and what I’ll call “derived operations”. Simple management says that all collections of virtual functions present a MIB that loosely corresponds to what a real device that provided that set of functionality would present. This fits into current management systems, but the problem is that virtual functions have resources that connect elements and host elements, and these resources are part of their management domain but not part of a device MIB an equivalent real device would present. How then do you manage them? A link between two pieces of a virtual customer gateway, for example, is explicitly a manageable element in a service chain, yet there’d be no such thing in a real device MIB. Then there’s the problem of shared resource collision. A bunch of virtual functions all depending on a single resource could swamp it with management polling. The functions could also change variables that would impact overall operation, destabilizing the service and presenting a major security risk. The alternative is to provide a highly composable management strategy, but here again you need to understand exactly how it works.
The sixth point is how does this NFV implementation deal with services that are deployed across multiple resource pools, multiple cloud providers, or even across operator boundaries? “Federation” of NFV services is critical because virtually no credible NFV consumer would ever be running without partnerships in the cloud or carrier sense. If you can’t provision and manage across a mixed pool of resources or build services that are implemented by partner carriers, most of your customers are going to get unhappy fast. And if vendors persist in having their own proprietary NFV strategy, it may be impossible to even support multi-vendor networks without federation capability.
The final point is who’s selling and guaranteeing this? NFV is complex in that it mixes software systems, management systems, servers, networks, you name it. All of this could become a harmonious machine working to support your profit/revenue goals, or a pile of disorderly junk. Who do you go to if the latter is what happens? Will you have to integrate all of this on your own, or is there some single source? Some operators don’t mind being an integrator, but most tell me they would prefer someone bid that role. Will your integrator bid it? Will the NFV provider be a suitable integrator for NFV? Are there things that will fall into the responsibility cracks—things outside “NFV” but inside the services that contain NFV elements? You need to know how this will work.
NFV is the tip of a gigantic iceberg, the issue that is forcing us to reconsider how we build and manage services. It could be the start of something big, something different. It could be a reprise of the same old vendor-specific crap. Most of the benefits claimed for NFV will never be realized unless buyers demand answers to these questions. Reporters too. If you care about the network of the future, then you need to care about these seven points.