The Empire Strikes Back

Cisco is back and badder than ever, with a new entry into the software-defined networking field. Per Jim Duffy at Network World, Cisco has announced the OpFlex protocol, its next salvo in the SDN wars, and a key part of Cisco’s Application Centric Infrastructure. Actually, shouldn’t it be Application-centric Infrastructure? AI is taken, I guess.

In case there was any doubt, this ain’t OpenFlow. The single most characteristic element of OpenFlow is the concept of separating the “control plane for the data plane”, or alternatively “smart controller, dumb switches”. Being in the business of selling smart switches, one could hardly expect Cisco to harmonize here. What’s it all about?

The easiest way to see where Cisco’s new entry fits is to contrast “classical” networking with OpenFlow. Ultimately, in either model every forwarding decision is made by the forwarding device inspecting incoming traffic, and comparing the parameters of that traffic against an internal “lookup table”. The main difference is how that lookup table is populated. In “classical” networking, the lookup table is populated algorithmically; the network engineer configures some parameters, but the bulk of the information used to populate the lookup table comes from information learned from network traffic or other devices.

In OpenFlow, the lookup table is populated by appealing to the centralized controller. The forwarding device is not capable of populating its lookup table on its own; all information must come from the controller. As I’ve discussed before, the advantage of this approach is that you can do anything, the disadvantage is that you have to do everything.

Cisco’s approach has features in common with both models. Like OpenFlow, the Cisco ACI includes a centralized management component, but that’s pretty much where it’s similarity to OpenFlow ends. The central management is specifically not responsible for forwarding decisions; that function is still devolved to the forwarding devices. Rather the central management function is in charge of dictating “policy”, with the devices being smart enough to implement that policy, i.e. populating their own lookup tables based on policy directives from a central source.

According to Cisco, OpFlex implements a “declarative” model of management, where OpenFlow is an “imperative” model. Digging back to third-grade grammar, I seem to remember that declaratives are statements of fact, while imperatives are direct commands; so basically OpFlex is the Jean-Luc Picard of SDN, while OpenFlow is the Jim Kirk of SDN. Crikey, can’t anybody say anything plainly anymore?

I hate to seem like I’m bashing Cisco, but everything they’ve put out about this reeks of vaporware. They know SDN could eat their lunch if they don’t respond, but they don’t seem to have anything new to say. Cisco has been trying to sell centralized management/policy solutions for their networking gear for years; they may have brought in their third-grade teacher to do marketing, but there’s nothing new under the sun.

Cisco must know that the appeal of OpenFlow is not centralized management; this is a demonstrable weakness in the architecture from a robustness perspective. The appeal of OpenFlow is the ability to manipulate traffic flows to provide “Layer 4-7 services” without buying new boxes; the need for a centralized orchestration mechanism to enable this is an unfortunate side effect. But Cisco’s response is: centralized management.

It is tough to blame Cisco; they sell hardware, and a big selling point of SDN is buying less hardware. There just isn’t any way for them to really sing from the SDN hymnal. They are trying, but the result is definitely off-key.

Comments are closed.