It’s probably not going to surprise anyone to hear that Cisco is going to be providing more detail on its SDN and NFV framework at its own partner conference in later January, given that Juniper took its shot this week. The two companies have always tried to pee in each other’s yards, stepping on announcements and muddying up waters. Who was first and who was stirring the pot here is impossible to say, and it probably doesn’t matter much anyway.
Cisco’s approach to SDN and NFV has always been rumored to be API-and-orchestration, aiming at defining the properties of the network “black box” by defining its external interfaces. I’ve noted in the past that there are three models of SDN; the virtual-network Nicera model, the purist OpenFlow model, and the “black box” model that focuses not on HOW SDN works but on what it does. It’s been clear for some time that Cisco intended to target the latter model, and that’s a smart play for two reasons.
Reason one is that right now the advantage in the SDN world lies with the black box model, simply because that model can accommodate current equipment and protocols and because it doesn’t depend for functionality on “northbound APIs” from OpenFlow controllers that lead (at present) to nothing in particular. The higher layers of SDN (the “Topologizer”, “SDN Central” and “Cloudifier” layers of our model, explained on our YouTube channel and our OhNayItShay website) don’t exist yet. Thus, purist SDN necessarily lags, letting Cisco establish an SDN model it favors.
Reason number two is that competitors have been ineffective in countering Cisco’s early moves, which suggest that Cisco can gain significant competitive advantage by moving SDN forward more aggressively than it otherwise might. Juniper’s “SDN” announcement this week appeared to be a quick cobbling of principles (the “Seven Myths” in Bob Muglia’s blog) and some product concepts drawn from QFabric and its chips, and from the Universal Edge announcement last year. None of the other competitors have really told an SDN story, so Cisco is like a racehorse who broke fast from the gate and found everyone else trotting. You don’t stand around in that situation, you RUN!
Where to? The story I hear is that Cisco is going to frame network services in the network and in the cloud (the service layer, including NFV) in a single set of APIs, which Light Reading and Network World are already reporting as OnePK in a kind of expanded mode. Currently the API set harmonizes development of various Cisco network OSs, and it includes things like route services that are essential to building that higher SDN layer, as well as for NFV support. They supposedly plan to incorporate hooks into OnePK that would provide a more versatile control link to network devices, something needed if you’re going to cloud-host functionality based on NFV or to build a tightly-coupled service layer in the cloud. They’ll also be providing componentization and orchestration of service-layer elements, which is likely what they mean by “slicing”.
How well Cisco fills their black box is important from a competitive perspective. Juniper took its shot already and failed to establish a compelling SDN position, so now Alcatel-Lucent, Ericsson, HP, Huawei, and NSN all get an at-bat once Cisco has laid out its positioning. That means that Cisco has to do enough to fend off rivals who will be able to dissect their weaknesses (or read them here!) and counterpunch. But no matter what, those SDN layers I’ve been talking about all along are table stakes. You have them, you explain them, you link them to the cloud and to the network, or you don’t have SDN. It’s a simple litmus test, but it’s fair and effective IMHO.
I also think that the real issue for networking is NFV, more even than SDN. That’s one reason I think Juniper should have labeled its NFV story for what it really was and made that point positively. You can argue that SDN is a proper subset of NFV, in fact, and we’re presenting an architecture for NFV hardware aimed at the space where NFV and SDN are most likely to be focused early on (the metro network) in our January Netwatcher tech journal.
The importance of NFV is that it pulls network functionality out of devices, something that’s reflected in both Cisco’s and Juniper’s focus on software licensing. Obviously adaptive discovery and route control could be examples of that functionality, which is why I say that SDN is a subset of NFV. For Cisco (and Juniper) the question now is whether they should support NFV to allow operators to focus on non-transport/switching functions or support SDN to allow operators to obtain quick network-level benefits. In either case, network vendors lose in the long term because everything that transfers functionality out of the network transfers differentiation and margins along with it. That may be why Juniper says their “SDN” won’t be in place till 2014/2015 and why Cisco may still drag its feet.
Two truths intrude here, though. First, you can stick your head in the sand only as long as everybody does. Otherwise you risk having your body eaten. Alcatel-Lucent, Ericsson, and HP in particular could gain significant competitive advantage by playing SDN and NFV correctly. Second, every vendor had a chance to build “network functions” that were incremental to current services and not displacing of them. Operators wanted revenue-driven transformation five years ago, and consistently told me that they were frustrated by a lack of vendor support. Well, vendors, you should have supported them. If you had, you’d be fighting over who gets the lion’s share of a growing pie and not the hyena’s share of the carcass.