OpFlex: Another example of Cisco being Cisco

Cisco's alternative to OpenFlow could put the company in a good position in the software-defined networking market.

Why do customers pay a premium for Cisco? My research shows that Cisco owns about 75% of switching share but only about 55% of port share, showing Cisco’s obvious revenue per port advantage over everyone else. Why does this discrepancy exist? I know some of you will disagree with this, but in general, customers pay up for Cisco infrastructure because it does more stuff faster than competitive products.

One good example of this is the evolution of power over Ethernet (PoE). Years before the PoE standards were ratified, Cisco rolled out its own version of PoE that gave customers PoE capabilities, while the rest of the industry was arguing in the standards bodies. Cisco got a huge, early-mover advantage by having a solution two years ahead of the field. Then, when the standard was ratified, Cisco supported it.

Cisco has maintained this advantage as remains the only vendor with 60W POE today. There are many, many examples of this. EIGRP is a faster, better protocol than RIP; for years Skinny had more features than SIP; EtherChannel was great for port aggregation, and the list goes on. Some vendors scream “vendor lock in” and “proprietary,” but the fact is that Cisco supports all the standards. But customers prefer the Cisco version since it does more.

This week at Interop in Las Vegas, Cisco announced an alternative for OpenFlow called OpFlex. OpenFlow is a standards-based way of managing a software defined network (SDN). OpFlex can be thought of as the equivalent for Cisco’s Application Centric Infrastructure (ACI), which actually solves a much bigger problem than SDNs.

OpenFlow manages an SDN by decoupling management and control intelligence from the infrastructure and centralizing it in an external controller. The OpFlex protocol operates by keeping the control intelligence in the network itself, making the network the foundation for ACI instead of ceding the control to a much slower, software-based external controller.

OpFlex is designed to support a declarative-control model in a data center rather than legacy-imperative control models. Declarative-control systems have better scale, resiliency, and most importantly, interoperability than imperative systems. Cisco backed up the interoperability claims by highlighting several notable OpFlex partners, including Microsoft, Red Hat, Canonical, F5 Networks and IBM.

The OpFlex protocol offers tight policy integration between devices of any form factor and the ACI infrastructure. This includes virtual switches, physical infrastructure, application delivery controllers, security products, storage, and servers. OpFlex works by abstracting the policies and relies on intelligent, autonomous devices to interpret them, hence the declarative control. This gives ecosystem partners the opportunity to innovate and expose new features without compromising interoperability.

Although OpFlex is a Cisco protocol, it is an open protocol and any vendor can become an ecosystem vendor. Cisco has committed to providing an open source agent under an Apache 2.0 license that other vendors can adopt and used. From what I understand, Cisco has also proposed OpFlex as a standard to the IETF, so we will see where it goes from here.

I believe Cisco is committed to keeping OpFlex open. Given the relative share the company has in the data center and the number of ACI partners that are market leaders in their own right, Cisco has a shot of making OpFlex a de facto standard, which in turn would make ACI an equally strong de facto standard.

OpFlex gives customers a fast path to infrastructure interoperability, albeit it on top of a Cisco network, which becomes the control point of the data center. An important note is that Cisco will also support OpenFlow, but OpFlex will allow customers to do more stuff faster, and I believe that customers will pay up for that.

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2014 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)