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.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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 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.