Two Tales of One City

The market giveth, and takes away, but probably in the main it’s the vendors’ own actions that make the difference.  We have an interesting proof point of that in two events yesterday—the end of the second NFV meeting in Santa Clara and the earnings call of Juniper, just down the road in the same town.  Same town but two different worlds.

NFV is a poster child for carrier frustration and vendor intransigence.  I’ve surveyed operators since 1991 and many who have followed my comments on the results will remember that about five years ago, operators were reporting themselves as totally frustrated with vendor support for the operators’ monetization goals.  Well, guess what?  They got frustrated enough to start an organization dedicated to the transfer of network functionality from devices to servers.  Nobody listened five years ago; maybe this time it will be different.

Juniper is a player who on the surface should be a major beneficiary of initiatives like NFV.  Juniper was the founder and champion of the “Infranet Initiative”, which became the “IPsphere Forum” and was later absorbed by the TMF.  This early activity wasn’t aimed at pulling functionality out of the network but rather in laying functionality onto/into it, admittedly using software and hosted elements.  Many of the agility, operationalization, and even federation needs of NFV hark back to those old IPsphere days.

But where is Juniper on NFV?  They’ve been bicameral.  The company has blogged about the topic, as well or better than anyone else in the vendor space, but in public they have not only failed to exploit NFV in positioning (and thus exploit their topical expertise, gained from their past activities) but have actually taken NFV concepts and stuffed them into an SDN brown paper bag.  I commented at the time that this was an illogical step, and I think the explosion of interest in NFV proves that Juniper rode the wrong horse to the show on this one.

And perhaps on other things too.  The tagline to remember from Juniper’s earnings call was from Rami Rahim, who said “It’s clear that traffic is continuing to grow and this forms of course the foundation of much of our business. So it just comes down now to how much of a risk operators want to take or how hot they want to run their network before they want to invest. Clearly as long as that traffic continues to increase, which we see as increasing everywhere, that investment cycle especially in cost centers like the core will come, eventually.”  This sure sounds like “lie back and hope the money comes in”, which isn’t the kind of innovation-driven approach to the market that an aspiring player with a minority market share and a P/E multiple of four times the market leader should be talking.

The contrast with the coincident NFV event is striking.  Let operators buy routers to carry traffic despite declining revenue per bit and return on infrastructure, at the same moment as these same operators are convening an organization to disintermediate at least some of the devices you make.  Go figure.

NFV has its challenges, not the least being that the body is still dependent on the vendor community’s willingness to come up with solutions to fit the body’s requirements.  The goal of improving cost and agility by hosting network functions seems (and is) logical on the surface, but the devil is in the details.  If you replace a fifty-dollar residential gateway with three virtual machines and the intervening connectivity to link the functionality, you’ve likely created something whose capex/opex contribution is greater than what you started with.  It’s also not clear how functional agility offered by virtual residential gateways versus real ones would help sell new services to residential users.  Simple virtualization of networks on a device-for-device basis isn’t going to generate enough savings to matter, and the basic architecture of networks and services wouldn’t be changed.  If you’re going to do NFV, you have to do it with an eye to exploiting the cloud—which is the model of the new fusion of IT and networking.  The cloud, as a platform for applications, is an equally sound and flexible and cost-optimized platform for service components.  Because, gang, services are nothing but cooperating software application elements sitting on a network.

Everything that Juniper, or any other vendor, would need to fully realize the vision of NFV (even before the body is able to fully articulate how they expect that to work) is in the marketplace today in the form of proven technology.  Every insight needed to make network equipment into an optimum platform for the new network, the network the operators need to be profitable and continue to buy hardware, is not only visible but glaringly obvious.  That there were over 200 attendees at the NFV meeting suggests that carriers are committed and vendors are at least wary that the concept might just happen.  It will, because it has to.  It’s just a question of who it will happen with, and Juniper will have to take its eyes off the bits to smell the NFV roses.  So will everyone else.

Leave a Reply