What MWC Contributed Overall to the Sense of NFV

MWC generated a lot of ink, and some of the developments reported by Light Reading, SDx Central, or both create some nice jumping-off points for comments.  You’ll probably not be surprised if I have a different spin on many of the things I’ve chosen, and that I hope we can gain some overall sense of where things are going with NFV.

One thing that struck me was the continued tendency of the media to talk about an “NFV architecture” or “NFV strategy” even when what’s being discussed is at best just a piece of NFV functionality and at worst isn’t really any piece at all.  It’s frustrating to me, because I think operators who are trying to get the range of NFV are hampered by lack of any organized placement of the offerings.

One example of a questionable use of the terms is the series of OpenStack-related stuff.  There is no question that OpenStack will dominate the deployment of VNFs, but OpenStack is not orchestration, it’s a part of the Virtual Infrastructure Manager.  So are any DevOps tools linked to NFV deployment, and so (IMHO) is YANG.  Because the ETSI ISG’s description of what the NFV Orchestrator does is rather vague (and seems to overlap with other descriptions for VIM and VNF Manager), and because deployment is orchestration at one level, we seem to be conflating OpenStack and orchestration and then MANO.  That’s not good.

On the NFV Infrastructure side we have a bit more logical positioning to report.  I noted last week that we’d seen the beginning of a separation of NFVI from the rest of NFV because the hosting part of NFV is where most of the capital dollars will be spent.  One news item that expands on my point was the announcement by Red Hat and Amdocs that the Amdocs Cloud Service Orchestrator has been integrated with the Red Hat Linux stack.  It’s not rocket science to make a Linux app run on a specific version of Linux, but this shows that Red Hat wants to have a role in NFV’s success should there be a big adoption wave.  Amdocs is interesting as a partner because they’re really more a player at the service side of the NFV story.  Were they unusually interested in getting some ink of their own, or does Red Hat’s move indicate it thinks that service integration and orchestration will be big?

Another example is the Telecom Infra Project spin-out from the Open Compute Project.  OCP is an initiative started by Facebook to drive hosting costs down by using a standard (commodity) design.  Facebook has blown some specific kisses at telecom, and certainly they would benefit if telecom costs were to be reduced to the point where it would drive down service prices, thus facilitating more Facebook customers.  I don’t think NFV in any form is likely to have an impact on consumer broadband pricing, however; certainly not in the near term.  This move could have an impact on NFV hardware vendors like Dell and HP, and since Intel is involved in the project it could be another data point on the path toward an Intel-driven attempt to get those optimum 100 thousand data centers deployed.  You can bet Intel chips will still be inside.

The cost angle raises the point that Orange has indicated some dissatisfaction with the cost-based justification for NFV.  My own contacts seem to think that the issue is not so much that cost-based justification doesn’t work as that capex reduction as a driver won’t work.  Opex reduction, says my contacts, is still much in favor at Orange (and everywhere else in the telco world), and most operators believe that the same service automation capabilities that would generate opex reduction would also be necessary to facilitate new services.  That’s what Orange is said to favor over cost reduction, and if the same tools do both opex and services, then it makes sense to presume this is yet another repudiation of the simplistic save-on-capex slant on NFV justification.  That approach has been out of favor for two years.

The opex and services angle might be why we had two different open-source projects for NFV announced—OPEN-O and Open Source MANO (OSM).  Interest in the first group is high in China (and of course among big telco vendors) and in the latter high in Europe.  While OSM demonstrated at the show, it’s not clear to me just what their approach looks like in detail because their material doesn’t describe it at a low level.  OPEN-O has less to show at this point than even OSM.  The fact that there are two initiatives might be an indication that China wants to pursue its own specific needs, but it might also mean that nobody likes where we are and nobody is sure the other guy can be trusted to move off the dime.

Even given the mobile focus of MWC, there still seemed to be a lot of noise related to service chaining and services that use the concept.  In the main, service chaining is useful in virtual CPE applications where a virtual function set is replacing a set of appliances normally connected at the demarcation point, in series.  I have no doubt that service chaining and virtual CPE are good for managed service providers targeting businesses, but I’m not convinced that they have legs beyond that narrow market niche.  Unlike mobile infrastructure, vCPE doesn’t seem to pull through the kind of distributed resource pool that you need for NFV to be broadly successful.

There was a lot of skepticism on whether the NFV focus on 5G was smart.  It’s not that people don’t believe that NFV would be good for (and perhaps even necessary for) 5G success, but that 5G seems a long way off and NFV might have already succeeded (and not need 5G pull-through) or failed (and wouldn’t be helped then by 5G).  I think that operators are anxious to see how 5G would impact metro mobile backhaul, and they need to know that pretty quickly because they are already committed to upgrades there to support WiFi offload and increased 4G cells.  This may be a case where a little hype-driven forward thinking actually helps planners unload future risks.

It seems, when you look at the news out of MWC overall, that NFV is kind of splitting down the middle in terms of vendor positioning and operator comments.  On one hand, operators and some vendors are getting more realistic about what has to be done to make NFV a success.  That’s resulting in more realistic product positioning.  On the other hand, this industry hasn’t had much regard for facts or truth for years.  Technical media isn’t too far from national media, where coverage of nasty comments always plays better than coverage of issues.  Excitement is still driving the editorial bus, and that means that vendors who overposition their assets are still more likely to get ink than those who tell the truth.

The thing is that you can only argue about what UFOs are until one lands in the yard and presents itself for inspection.  We’re narrowing down the possible scenarios for NFV utility even as we’re broadening the number of false NFV claims.  I think that by the end of this year, we’ll start to see a narrowing of the field and a sense of real mission…finally.