News Stay informed about the latest enterprise technology news and product updates.

Competitors on Cisco SDN protocol OpFlex: Show me the code!

Cisco will submit its OpFlex SDN protocol to the IETF for standardization, but will the technology promote a closed, hardware-centric version of SDN?

With its OpFlex SDN protocol, Cisco says it will be able to dynamically program policy across even multivendor networks, but competitors question whether the company will ever make the technology open enough for them to adopt. 

Competitors also suggest OpFlex standardization is simply a tactic Cisco is using to legitimize its Application Centric Infrastructure (ACI) as an SDN technology.

OpFlex is a southbound protocol that allows a central controller to pass policy and configuration commands along to network devices. This type of programmability makes the infrastructure dynamically responsive to the needs of applications.

The protocol is central to Cisco's ACI, which relies on proprietary switches with distributed intelligence and centralized policy control. Other SDN strategies aim for a more software-centric approach that disaggregates the entire control plane into a central controller that speaks to a network of much more basic -- even commodity -- switches.

Cisco will submit OpFlex to the IETF for standardization, which means the protocol will be published and could be adopted across the industry. Cisco is also working on a project with the OpenDaylight Consortium, called the Group Policy Initiative, which will let its OpFlex controllers extend policy control across any vendor platform that supports the protocol -- Midokura and Plexxi are involved in this project. 

If Cisco OpFlex is open, where's the code?

Other vendors that are knee-deep in SDN development -- even those that are open to using OpFlex --say it's a bad sign that Cisco hasn't yet revealed the code behind the technology.

Carl Moberg, vice president of technology at Tail-f Systems, said Cisco has merely "published an informational draft," which is a far cry from submitting code for an actual IETF standard. "It carries zero weight," he said. Of the half-dozen companies interviewed for this story, including some that are involved in OpenDaylight, none had gotten their hands on OpFlex code yet.

There is a major difference between a standard that is published and one that is open sourced for community contribution and development, said Kelly Herrell, vice president and general manager of the Software Networking Business Unit at Brocade. OpenFlow, for example, is fully published and any member of the Open Networking Foundation (ONF) can contribute to its development. OpenDaylight is another example of an open source SDN development community.

Whether open or not, OpFlex relies on sophisticated hardware and a distributed control plane, which plays into Cisco's business model and not necessarily the goals of SDN.

"The industry is clear in its demand for truly open standards and wary of 'Trojan horse' lock-in strategies. History has shown that proprietary protocols almost never win, especially when disguised as open, as is the case with Cisco's proposal," Brocade's Herrell said. "Brocade's strategy is in stark contrast to this approach, working with partners and customers to advance and leverage SDN/NFV technologies based on truly open standards," But Neela Jacques, executive director of OpenDaylight, says Cisco's OpFlex moves reflect a philosophical difference between companies "that believe in a much more radical centralized intelligence" and those like Cisco that believe "there is tremendous value in the underlying hardware." Cisco is revealing its "secret sauce" for the first time instead of remaining closed, he said.

"Cisco is saying 'I want this to be an open standard'," said Jacques. "There is an understanding that a single vendor solution is not what the end user is looking for." Cisco also understands that if it can get others to "join the bandwagon" the broader support will be good for them. With an OpenDaylight controller, for example, users could eventually choose between either SDN strategy, he said.

Policy wars: OpFlex vs. OVSDB; Cisco vs. VMware

Some have likened OpFlex to OpenFlow since both are southbound SDN protocols, but OpFlex is more comparable to the Open vSwitch Database (OVSDB). OVSDB is the protocol that sends management and configuration policy across Open vSwitches -- VMware uses OVSDB for policy and management in NSX overlay environments.

OVSDB allows configuration to be addressed on network fabric and overlays, said Nick Lippis, founder of the Open Networking User Group (ONUG) and the Lippis Report. OpFlex is the first alternative protocol to come along promising to do the same. However, there is no way of telling which will be more effective since neither is truly in action, he said.

More on Cisco SDN developments

Cisco APIC controller extended to campus and WAN

Cisco's commercial OpenDaylight controller

Cisco and VMware: Which will network pros choose?

Why VCE Vblock won't die in the Cisco-VMware battle

Competitors sound off on Cisco ACI

Cisco "is doing the right thing" by open sourcing an OpFlex agent with a license that is similar to Apache 2.0, Lippis said. Whether the market adopts that remains to be seen.

It's very likely that the industry will align into two camps, with VMware using VXLAN as its tunneling protocol and OVSDB across its Open vSwitch implementation and Cisco using OpFlex and some combination of OpenFlow and other southbound protocols. At Interop last week, VMware CTO of networking Martin Casado said the company could feasibly adopt OpFlex if it is good enough and truly open. He also noted that it's very unlikely that Cisco would do the same with OVSDB.

Neither has much bearing on OpenFlow, which could play a role in any infrastructure that runs OpFlex or OVSDB. A network could rely on OpenFlow to send flow commands, while OpFlex passes along policy control.

Cisco OpFlex and OVSDB will both work in OpenStack environments

When Cisco announced it would submit OpFlex for IETF standardization, the company also highlighted a few partnerships, including one with Canonical that would extend Ubuntu OpenStack orchestration support for OpFlex.

"We want OpFlex… to interact with Open vSwitch components and have those things connected using our orchestration tool," said Mark Baker, Ubuntu server and cloud product manager.

The goal for almost anyone operating a cloud at this point is to orchestrate across networking, storage and compute. Interfacing with both OpFlex and OVSDB will be crucial in an OpenStack environment.

Meanwhile Casado told SDNCentral at Interop last week that he had been involved with an OpenStack project called Congress that will push "policy as a service" across networking, storage and compute for cloud services. Casado said the initiative includes a group policy framework that goes beyond what Cisco is doing with OpenDaylight and that the goal is to avoid any one vendor controlling policy framework.

Michelle McNickle contributed to this report.

Let us know what you think about the story; email Rivka Gewirtz Little, executive editoror follow her on Twitter @RivkaLittle.

Dig Deeper on Network protocols and standards

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Will OpFlex adoption lead to Cisco ACI dominance in the SDN market?
Although Cisco does have the muscle required to monopolize a South-bound protocol, there are too many vendors out there supporting OpenFlow which has proven, alongwith code and specs, to be a very standard south-bound protocol. A lot of products have already been incorporated with OpenFlow support. And SDN is one of those domains where the incumbents may not be able to easily dominate the new players
@raseel, do you have picks on vendors using OpenFlow that you think will make a dent in the market?
Just like the article said OPFLEX is a Trojan Horse meant to validate Cisco's strategy of selling high priced gear along with their version of "Hardware Defined networking" . Why can't Cisco use OVSDB if they want to play nicely and truly be a part of the open source community
I worked at Cisco for 12 years. They will use OpFlex to get "some" proprietary hook into Cisco hardware and lock customers in. That is why they are dragging their feet in SDN in general. They are no longer bigger than the market but unfortunately they do not know that yet. OpenFlow is being deployed now by Internet2, Service Providers, NSF for all university level science projects. By the time they get OpFlex published, through the IETF, and out into the public, OpenFlow will have non-trivial market maturity and customer adoption. Lets be honest, Cisco has their whole business built on hardware, they cannot try to transition that revenue to software too quickly or they will dissapoint their shareholders in a large way. They are all about tapping the brakes.
cisco is trying to make this as their proprietary implementation
Cisco continues to look for ways to bind solutions to their high margin, costly h/w. Not surprising given their need to postpone any market contraction inevitable in the coming software networking realm. In the end, I suppose it begs the question "will open code solutions be successful"? Or are we all tilting at windmills?
Because OVSDB and OPENFLOW Control protocols are already in operation across most of the the virtual switch market and a large part of the shipping Physical Switches supporting OPENFFLOW.
Cisco needs opflex to make aci succesfull, L2/3 is not enough! Cisco needs L4-7 vendors on the train as wel.