In positioning its OpFlex policy protocol and the declarative policy programming model in which it operates, Cisco marketing officials noted repeatedly how it was an optimal southbound protocol alternative to OpenFlow, OVSDB and the imperative network programmability model preferred by many others in the industry, including VMware - sans OpenFlow. But Cisco engineers took umbrage with our characterization of OpFlex as an OpenFlow killer, and are even uptight about its interpretation as an OpenFlow/OVSDB alternative.
For the record, we said OpFlex was an OpenFlow SDN killer - meaning SDNs based on OpenFlow's imperative, disaggregated and decoupled control/forwarding architecture, which we feel is consistent with how Cisco is positioning its overall Application Centric Infrastructure in the larger SDN context: as an optimal alternative to, and yes, a discouragement or inhibitor or deterrent to imperative SDN adoption and proliferation. We are not the only ones with this understanding.
All that aside, Cisco engineers need to have their side of the story heard. Kyle Mestery has an excellent blog here on how OpFlex the policy programmer can leverage OpenFlow and OVSDB, the network programmers, to instill policy into the network infrastructure:
OpFlex is meant to be embedded in the device or host via the Policy Agent. This could be a virtual switch such as Open vSwitch, a whitebox switch, a load balancer, a firewall, or any other element which can enforce policy...
the key pieces of OpFlex are the Policy Authority and the Policy Agent. Policies defined in the Policy Authority are resolved asynchronously by the Policy Agent. The policies are then rendered in the system specific implementation into the programmability functions provided by the device or system. Examples of programmability functions could be the OpenFlow and OVSDB protocols supported by Open vSwitch, APIs provided by Arista's EOS, the onePK APIs supported on Cisco gear, or even a CLI interface to a firewall device. OpFlex doesn't replace the programmability mechanisms provided by the system, it works in tangent with them to enforce the policy. This is the key piece which many have missed...
OpFlex is not meant to replace Open vSwitch, nor any other host or system programmability layer. Open vSwitch is a great Open Source project for which Cisco is a contributor. We plan to continue working closely with the Open vSwitch community, as well as projects such as OpenCompute, OpenDaylight, and the ONF.
All good. At the same time, however, Cisco criticizes OVSDB and imperative SDNs -- and partner-turned-rival VMware's strategy -- in this white paper describing the role of and raison d'etre for OpFlex:
many of today's SDN solutions increase complexity by separating virtual and physical domains while offering little or no visibility between the two. Many solutions suffer from scalability and performance limitations that result from the use of a centralized, rather than a distributed, control plane. Additionally, they tend to use fixed, rigid schemas for interaction with devices, effectively reducing the network to a lowest common denominator feature set. For example, a protocol such as the Open vSwitch Database (OVSDB) management protocol allows configuration of only basic primitives such as ports and bridges and cannot easily be adapted to expose vendor innovations...
Declarative control systems such as Cisco ACI offer a number of advantages over imperative systems such as VMware's NSX...
Finally, declarative systems, which allow policies to be specified in abstract terms, have strong interoperability characteristics. Multiple vendors can consume and honor the same policy without the need to have identical hardware configurations or software versions. In fact, vendors can continue to innovate on their platforms and expose new features as long as they honor the semantics of the abstract policy. This approach thus removes the lowest-common-denominator limitation established by today's software-based overlay solutions.
All of this is to be expected. Cisco does not want to endorse VMware's strategy any more than VMware wants to endorse Cisco ACI.
So was it a stretch to label OpFlex as an OpenFlow SDN killer in the context of the OVSDB imperative model and VMware's strategy? Perhaps. It's clearly an alternative as well as a complement, just as ACI is an alternative to the decoupled/disaggregated SDN. The more accurate target for OpFlex is OVSDB. One exasperated OpenDaylight contributor and developer told us Cisco could have easily extended OVSDB to do what OpFlex does but chose instead to write a whole new protocol. This is the way Cisco does things.
And though it can work within an OpenFlow/OVSDB SDN, Cisco wants you to buy OpFlex and ACI, and not buy OpenFlow/OVSDB and VMware's NSX and upcoming OpenStack Congress policy model. Anything to the contrary would be very unlike Cisco, all "open" positioning and posturing acknowledged.
Speaking of OpenStack Congress, which is being driven by VMware, its declarative policy model is intended to be southbound protocol agnostic - it will support OpFlex, OVSDB or any other policy management protocol of the customer's choosing.
"It doesn't matter," says Tim Hinrichs, software engineer at VMware, and one of the developers of Congress. "Choose any reasonable protocol for communicating policy, and we're happy. We'll support them all."
And there's dialogue between OpenStack Congress and OpenDaylight group policy model developers on linking the two so the broader Congress cloud policy framework can share information with the network-centric OpenDaylight policy engine, Hinrichs said.
More from Cisco Subnet:
Cisco, VMware take SDN battle to policy arena
Cisco looks at extending OpFlex
Cisco reveals OpenFlow SDN killer
Cisco challenger Arista files to go public
Cisco's cloud services reversal was inevitable
Cisco's big about face on cloud services
SDN changing the shape of networking, IT careers
Cisco execs address defective memory component issues with routers, switches
Cisco revamps enterprise product pricing
Take back the network
Follow all Cisco Subnet bloggers on Twitter.Jim Duffy on TwitterFollow