One of the “in-passing” comments made by John Chambers in Cisco’s earnings call was that the company was “We are pulling away from our competitors and leading in both the SDN thought leadership and customer implementations.” Interestingly there’s a strong element of truth in that statement despite the fact that Cisco is widely regarded as being anti-SDN, and that truth and the reason behind it may have important consequences beyond SDN. Cisco raises the question of whether less is more in addressing “revolutionary” technology.
Most people think of SDN in terms of the Open Network Foundation (ONF) and the OpenFlow protocol. This combination is supposed to revolutionize networking and the vendor space by changing the focus from adaptive L2/L3 protocols and existing switch/router products to central control of forwarding and white-box devices. Obviously vendors like Cisco (and all its competitors) are less than happy about that particular outcome, but many of the competitors have at least blown kisses at ONF/OpenFlow SDN because it might help them gain market share at Cisco’s expense.
From the first, Cisco’s SDN strategy has been one I’ve always described as supersetting. You defend yourself against a market development by enveloping its goals in a larger goal set whose implementation you can control better. Cisco came out with Application Centric Infrastructure (ACI) to do just that. All network forwarding behavior is a black box to the users of the network, so Cisco embraced the visible consequences of SDN in ACI, which taps the same benefits and thus lessens incentive for users to migrate. They even added concepts like a richer management and policy-based control framework, things lacking in formal SDN. Finally, they made ACI an evolution of current network technology and not a centralized white-box-and-standards-geeks revolution.
What supersetting as a concept relies on is the fact that revolutionary change tends to expose users to costs faster than to benefits. A user looking at their first deployment of purist OpenFlow SDN has to get a controller (new), learn to use it correctly (new operations practices), get white-box switches (from a new vendor), and then stick this whole thing inside a network that still largely works the old way. Cisco says “Hey, suppose we could give you what this SDN revolution thing is supposed to deliver, but without any of that expensive novelty?” You can see how that would be appealing.
Even if buyers are willing to look ahead a bit and value the new networking model, there’s still a set of issues. We know for sure that you can build a data center network from purist SDN. We know you can build a core domain that way. We know that it absolutely would not scale to the level of the Internet and we can’t even prove it would work at the scale of a decent-sized enterprise VPN. SDN “domains” have to be small enough for controllers to be able to handle, but it’s not clear how “small” that is. It’s even less clear how you connect the domains, unless you want to fall back on traditional L2/L3 concepts that is.
NFV faces an almost-identical challenge. What we can do with NFV today not only isn’t revolutionary, it’s often not even particularly useful. That’s largely because the early SDN applications simply don’t impact enough cost or have generate enough prospects for new services to impact either cost or revenue overall. You have to go big, but operators, like most buyers, will not overhaul their whole technology model for five or ten, or even twenty percent reductions in cost. I’ve quoted a good operator friend on this before: “If we want a 20% savings we’ll just beat Huawei up on price!”
We have to realign that problem of cost and benefit timing with NFV, perhaps even more than we do with SDN. In both SDN and NFV one of the biggest unresolved issues is the relationship between an “enclave of the new” and the vast network of the old. The specific challenge for NFV is that the necessary scope of benefits is much larger—opex efficiency, new service revenues, and capital savings. NFV raises early risks, creating more of the very thing that Cisco saw as a vulnerability of SDN-a-la-OpenFlow, and then exploited with ACI. Might Cisco have similar supersetting plans for NFV?
They might, indeed. Their Tail-f acquisition gives them a Yang/Netconf combination that lets them control multi-vendor infrastructure. Not only does this help them in their SDN supersetting by giving Cisco a way to extend ACI benefits across other vendors’ equipment, it provides Cisco with a solution to the end-to-end service control challenge that NFV so far has decline to address.
If you marry ACI with Tail-f’s ConfD approach and then stir in a little OpenStack, you’d have something a lot more useful than NFV would be alone. It’s not fully responsive to market needs in my view, but it’s better than “standard” NFV. And Cisco just announced a single-northbound-API version of ConfD would be free, making it either a nice camel’s proverbial nose or a kiss blown at purist NFV just as Cisco’s OpenFlow support is a kiss for purist SDN. Or both.
The most vulnerable period of any new technology is its initial adoption, because of that mismatch of pace-of-costs versus pace-of-benefits I opened with. Most buyers probably realize this; remember my comment that one of the top three NFV questions is “Where do I start?” even among those who have started? I also think that the reluctance or inability of both standards groups and vendors to take a big, full, bite of the issues up front contributes to this problem. Any uncertainty about starting a revolution tends to send people back to the coffee shop, favoring evolutionary approaches.
Cisco now has a policy-management strategy for handling SDN and NFV services. It’s not what I’d endorse as ideal, but it’s there, and better than a chasm of omission such as we get from many other vendors. Cisco also has a management/orchestration strategy with that same qualifier of “better than nothing”. They are singing well in a market where most of their competitors are tongue-tied. And they have servers, a cloud presence. All that adds up to their being a force in NFV in the same way as they’ve been a force—a winner—in SDN.
I think Cisco is winning in SDN and their supersetting strategy could win in NFV too. What could change the opportunity landscape for a competitor? Here’s my list of requirements a Cisco competitor would have to deliver on, and I want to point out that these same requirements exist for the cloud and SDN as well. Thus, it’s these three things that will determine whether Cisco itself has a lock on being the “next Cisco”, or whether somebody could still ride a revolution to that heady goal.
First and foremost strong service modeling using the “declarative” approach that defines objects and goals rather than scripting steps. This is something that HP and IBM can deliver for sure today (Cloudify probably can as well), and there may be others who can as well but haven’t supplied me the documentation. All deployment and management has to be based on this modeling.
Second and nearly as critical, integrated management that includes legacy infrastructure. That means you have to be able to deploy services edge to edge, and also to manage both legacy and NFV elements comingled in whatever way operators find useful. HP has this for sure, and I think Alcatel-Lucent, Oracle, and Overture have it as well. I think IBM could supply it but I’m less sure about them.
Third, federation of administrative “zones”. Operators will need to partner with other operators, and likely with cloud providers as well. Many will have to create arms-length subsidiaries that will need to create cooperative services across the border. Everyone will have to deal with how NFV domains link with legacy VPNs, the Internet, etc. Here I can’t name vendors because I don’t have enough information on anyone’s solution. In fact, I have doubts that anyone has a full solution here yet.
Federation has been ignored by vendors because it’s not as important in making the business case for NFV at present. It may be absolutely critical for getting that first NFV application or trial to expand, not only because partnerships are routine among operators but because early NFV enclaves are likely to develop from independent trials, and they’ll have to link up quickly or risk creating silos. Remember that absent NFV- or SDN-specific federation approaches you end up falling back on adapting legacy interconnect, and that favors Cisco’s evolutionary model because it works with existing gear by definition.
Little steps reduce risk in one sense and expand it in another. It’s fine to shuffle to success as long as your movement adds up to progress toward the ultimate goal. In SDN, Cisco is exploiting the shuffling of others by simply embracing the goal without the revolution. That could work in NFV and even in the next generation of the cloud, where cloud-specific apps will remake the landscape. It may be that standards groups and Cisco competitors alike have gotten too used to incrementalism as a means of controlling cost and risk, and don’t recognize that related notion of “critical mass”. You have to generate enough early benefits to justify ongoing commitment and growth in any new technology. Cisco’s SDN supremacy is proof that didn’t happen in the SDN space, and supersetting isn’t out of gas yet.
