Cisco is arguably the technology powerhouse of networking, not to mention the marketing gorilla and the emerging leader in the efforts of network vendors to broaden their base in response to declining capex. Network functions virtualization (NFV) is arguably the natural fusion of IT and networking, and a logical place for a vendor with broader server/switch/router aspirations to look to. So when Cisco blogs on the topic, with “Three Pathways to NFV Success…or How to Tame the NFV/SDN Monster”, you just have to read it. In fact, I recommend that you read it now, and read the full report available on Cisco’s site, before we look into the details.
I’ve surveyed operators since 1989, and I’ve been involved in NFV longer than the NFV ISG has existed. I was chief architect of the first NFV PoC approved, and was named one of the most influential players in NFV by Light Reading in the first summer of NFV’s work. I’m citing all of this to show that I have decent NFV credentials and contacts, and thus to validate my own views of the problem Cisco is addressing.
If there’s an NFV monster to tame, it’s that NFV adoption has been way more difficult than expected. Cisco presents three pathways to NFV success (technology transformation, service-based transformation, and cultural transformation), and they provide survey data to back up their view. My own surveys suggest that the Cisco results can and should be interpreted differently, but that the alternate interpretation can also be a pathway to NFV success.
What Cisco sees as three pathways to NFV is really more like three stages of operator denial. Everyone started their NFV exploration based on the 2012 “Call for Action” white paper, which suggested that NFV would succeed by substituting commodity hosting and inexpensive software for costly proprietary appliances. Within a year, the same operators who had promoted that first vision had accepted that there wouldn’t be enough capex savings, and that NFV would have to address opex. In another year, they realized that they needed to address revenues too, “service agility”. So, when Cisco’s survey found nearly 80% of respondents thought “Agility” was the prime justification for NFV, they were just saying that nearly all operators had followed the attitude evolution and were now in the end state…well, end state except one.
The last of the pathways, cultural transformation, really came about not from the operator side but from vendors and the media. Even at the end of 2013 I was getting complaints from NFV vendor sales types, saying something like “The problem with NFV is that buyers don’t understand that they have a Holy Mandate to buy the stuff, and they keep wanting a business case!” The media had their own problem, created by the fact that only sensational headlines get URL clicks. I always said in conference speeches that “To the media, everything is either the single-handed savior of Western Culture, or the last bastion of International Communism.” When NFV wasn’t taking off, the media picked up the “culture” story.
The facts are a lot simpler. Even Cisco’s survey shows that NFV projects are owned in two-thirds of operators by the technology organization, under the CTO. CTOs don’t make buying decisions, they validate technology. From the first, the operators’ real moneypeople, the CFOs, said that they were not seeing any convincing business case for NFV, and they still say that by a large margin. There are operators who have special interests, primarily managed services, and they have been able to justify a virtual CPE decision, but the truth is that today’s virtual CPE is more like the Verizon agile white-box strategy (you can load features into a CPE device) than like formal NFV. About 90% of “NFV” stuff now in progress falls into this category, yet only about 16% of respondents to the Cisco survey said that lack of a business case was the problem.
Because they’re not really trying yet. The majority of NFV projects are in planning or PoC, and this after four years of NFV progress. Proving the concept of NFV couldn’t possibly take that many PoCs and that long a period, unless you’re really not proving concepts but groping for an overall concept to prove. My own interpretation of where things are? It’s that operators are trying to balance between a concept of NFV that has very narrow boundaries directly related to getting virtual functions hosted, and a justification of NFV that demands automation of a complete service lifecycle across all infrastructure in order to achieve agility and opex efficiency. Right now, the first of the two is winning, and as long as that’s true, NFV won’t move forward.
We know that the “concept” view of NFV is still dominating by the Cisco survey data, too. If operators recognized the service lifecycle automation goal as critical, we would expect to see them focusing on OSS/BSS and CIO issues as being important. OSS/BSS gets only 4% recognition. Same with orchestration. In fact, only AT&T (with ECOMP) has any NFV model that has the scope necessary to actually make a broad business case, and while ECOMP has champions, it’s clearly not sweeping all alternative visions of NFV before it. And even ECOMP isn’t complete in terms of its lifecycle management automation support.
Cisco’s three pathways blog, then, doesn’t seem to really address the issues that seem to have created the “NFV Monster” their blog title cites. Particularly if Cisco, who has servers and server aspirations to transform their own business model, sees NFV as a pathway toward those carrier cloud data centers. Perhaps the biggest problem with Cisco’s strategy is that anything they try now has risks. Follow an open approach like ECOMP and you’re one vendor among many. Try to promote a proprietary model of NFV and you’ve taken on a project that AT&T says involves millions of lines of code. And, of course, there is simply no time to push such a model now.
What I’d love to see Cisco do is to frame a top-to-bottom service lifecycle management problem in service model terms, using YANG. Cisco bought the technology with Tail-f, and it’s time to either demonstrate that it can do the whole job, or admit it can’t and fit it into some broader service lifecycle management story. No technical evolution, or service evolution, or cultural evolution, to NFV can possibly succeed without making a business case, and no business case can be made without complete service lifecycle management automation.
You can dissect the “monster-driving” issues, say that the problem is the greed of the VNF vendors or the lack of interoperability at the VNF level, or the lack of specific standards for key interfaces and specific management metrics that can drive an SLA. All of that is just noise unless you have a strategy that can make a broad business case, and that strategy is not there today except, in a prototype form, in ECOMP. Just the fact that everyone hasn’t jumped on ECOMP already is proof enough that NFV at the heart is still just a science project. Unless Cisco is prepared to move NFV beyond that, their blog is just PR.