A Realist’s Guide to NFV

Generally, the realities of online journalism will tend to exaggerate everything.  A development, to be press-worthy, has to be either the single-handed savior of Western Culture, or the last bastion of International Communism.  NFV has gone through this gamut, and it seems like a lot of the recent stories are skeptical if not negative.  My number one prediction for 2014 is that the hype on NFV will explode, and even more reality will be swept under the rug of generating buzz and URL clicks.  So let’s look at where we really are.

First, the ETSI ISG’s work won’t complete till January 2015 so we’re a year from being done.  However, the framework of the architecture is in place at this point and so we know what NFV will look like as an implementation.  Vendors (and even operators) who really don’t want to do NFV may use the incomplete ETSI ISG process as an excuse, but it’s lame.  Those who are taking itty bitty NFV steps are doing that because they want to.

Second, the ISG’s work, in a formal specification sense, will increasingly be linked to forma proof-of-concept work that aligns implementation reality with specifications.  I’ve said many times that a five-hundred-page spec won’t write code and can’t be deployed on anything.  At some point NFV has to become software—in fact two levels of it (I’ll get to that next).  I can’t overstate how critical it is for implementations of NFV to be played with now, so there’s time to adapt the specifications to reflect optimum implementation practices.  I said that before this process ever got started, back in October 2012 and it’s just as true today.  We need prototypes.

Third, there are really two parallel NFV issue sets.  “Network Functions Virtualization” equals “Network Functions” plus “Functions Virtualization”.  Network functions are the things that will be run, and functions virtualization is the process of deploying and managing them.  Both are software, and we need to understand that the requirements for the two are interdependent.

For example, there are literally tens of thousands of open-source packages out there that might be harnessed as network functions, but they were not written to be deployed through NFV.  If we can adapt how they work now to NFV principles we have a rich inventory of stuff to start NFV off right.  If we can’t, then not only do we have to write virtual functions, we have to agree on the specialized interfaces and programming practices we decide are necessary.

Fourth, NFV isn’t enough.  When all this started, operators were thinking that they could deploy custom appliances as virtual functions and save opex based on the difference in cost between a proprietary appliance and a hosted function.  Well, look at home gateways as an example.  You can pick up one for forty bucks in Office Depot.  Mine has worked for at least five years, so the amortized capital cost (less cost of money and accounting mumbojumbo) is eight dollars.  Do you think an operator could deploy and host something like that for seventy cents a month?

Operators I’ve talked with and surveyed now agree that the value of NFV will come from its ability to reduce opex and to accelerate service velocity.  But NFV in the original strict host-appliance-logic-in-VMs form doesn’t address enough of the total service infrastructure to have massive impacts on either one.  What’s important is that NFV illustrates the need for virtualization of all the service lifecycle processes in order to be cost-efficient, and the way that’s done could revolutionize service management overall, even extending beyond “functions virtualization” into legacy infrastructure.

The next point, related, is that NFV is about managing virtualization in all dimensions.  Virtual functions, hosted in the cloud, and morphed into virtual service experiences is a lot of virtualization to manage.  Several years ago, the TMF actually framed the technical dimensions of the solution with their integration model (GB942).  The core insight there was that a complete abstract model of the service (the “contract”) has to represent the component and resource relationships in deployment, operations, and management.  Virtualization is a combination of creating valuable abstractions that are generalized to be flexible and agile, and then instantiating them optimally when they’re needed.  That doesn’t mean that NFV is about specific modeling or graphing, it’s about creating a useful abstraction in abstract.  How we then describe it in machine terms is an implementation finesse.

My next point is that NFV is an ecosystem.  You hear every day about this company or that who has “demonstrated NFV” and 99% or more of this is exaggeration.  You don’t demonstrate a race car by showing somebody a nut and bolt.  Every component of NFV already exists somewhere in some form, so trotting one out doesn’t make you an NFV player.  The ISG has published end-to-end specifications in early form, and those identify the functional elements of “real” NFV.  That which can address all these elements is “NFV” and that which cannot is simply a collection of some of the stuff that is included in “real” NFV.  We don’t need some of it, we need all of it.

The final point is openness.  The original target of NFV was replacement of purpose-built, proprietary, boxes by open virtual functions.  Operators don’t want to go from an age where vendors held them up for high-margin middle-boxes to an age where the same vendors hold them up for high-margin virtual functions.  What makes something “open” is the ability to freely substitute components at key places without having to re-integrate or re-program everything.  The ISG can do a lot to assure openness within its scope, but if most of the value of NFV comes from operations efficiencies and service agility that spreads out to cover all of the service management process, then all of that has to be open for openness to matter.

NFV is making good progress.  Yes, there are critical issues to be faced but they’re not the ones being talked about.  Most critical is the proof-of-concept stuff; we will never get this to happen without running prototype implementations and that is the absolute truth.  So if you hear an NFV story from a vendor, ask if they’re supporting a PoC.  If you hear speculation about implementation issues or the value of NFV, ask if the person doing the speculating is working on a prototype to develop their points.  And pay no attention to people who aren’t really involved in this, because they don’t know what’s real.  That’s my advice for what’s going to be a hype-ridden 2014.

Leave a Reply