As we continue our series on open networking standards, we'll take up a protocol that is sometimes touted as an "OpenFlow killer," namely OpFlex. That moniker, included in a headline to a Jim Duffy piece about Cisco's introduction of OpFlex in April 2014, is obviously an oversimplification. OpenFlow has plenty of traction, as does the Open vSwitch Database Management Protocol (OVSDB) that is widely used within OpenDaylight, Open vSwitch and some physical switches. So rather than focus on whether OpFlex or something else will win the SDN space, it may be more useful to think about how each protocol sets out to meet a specific vision for networking.
Designed and proposed to the Internet Engineering Task Force by Cisco, OpFlex foregoes the centralized, software-based controller of OpenFlow-based SDN and instead serves as the foundation for Cisco's Application Centric Infrastructure. It is to ACI what OpenFlow is to a large swath of other vendors' SDN switches. However, ACI is very much a hardware-based paradigm, in which switches at the edge enforce application-aware policy, associating it with packets before forwarding the traffic. Hardware platforms like Cisco Nexus 9300 and 9000 switches are used to perform these actions. while OpFlex provides a way to dictate and manage policies between endpoints.
OpFlex: A protocol for device-independent policy between network controllers and devices
More specifically, Cisco has defined OpFlex as an "extensible policy protocol designed to exchange abstract policy between a network controller and a set of smart devices capable of rendering policy." It is designed for compatibility across a wide range of hardware, making it economical and expedient for organizations to use, while theoretically encouraging innovations among vendors.
Whereas OpenFlow-based SDN uses an imperative model for forwarding control - i.e., flow policy intelligence is housed in the controller while the forwarding devices are dumb - OpFlex adheres to a declarative model. In practice, being declarative means that a policy manager initiates policies that intelligent devices can subsequently execute. Cisco has touted this declarative mode as more reliable and flexible than the OpenFlow-oriented alternatives, since it doesn't have a single point of failure (the main software-based controller). In this way, OpFlex, the company has pointed out, follows the design of popular DevOps automation tools.
"To implement declarative control, a new mechanism is required to transfer abstract policy from a network policy controller to a set of smart devices capable of rendering abstract policy," explained the Cisco documentation on this subject. "Unfortunately, existing protocols such as OVSDB favor imperative models with rigid schemas, so they are not appropriate for this use case. In fact, devOps tools such as Puppet or CFEngine take a similar approach to OpFlex in using declarative languages to configure server resources."
Of course, the elephant in the room is that the spread of OpenFlow presents a challenge to the core business lines of Cisco and other vendors. White box switches could be used in place of the pricier, specialized devices that have long been mainstays of networks as well as dependable profit centers.
The plan for OpFlex
Several vendors are already on board with the vision associated with OpFlex. Citrix, Red Hat and Microsoft all plan to build OpFlex into hypervisors and software. Others, like F5 Networks, may issue their own OpFlex agents.
Moreover, OpFlex, in addition to being submitted to the IETF, is going to be pivotal to OpenDaylight, the software project that we covered in the first part of this series. Cisco is one of the initiative's most influential members, meaning that while OpenDaylight is nominally a community effort, it is coalescing around the interests of its largest stakeholders.
"I don't know whether Cisco is wielding inordinate influence there, but it's clear Cisco is punching its weight in OpenDaylight," stated IDC analyst Brad Casemore. "The company has done stellar work ensuring that the possible outcomes enabled by OpenDaylight as a platform align with Cisco's product roadmaps and strategic initiatives."
Still, OpFlex isn't what comes to mind when many hear the term "SDN," in that it's so much different than OpenFlow et al. Cisco still has to work on justifying the differences' benefits for the networking world. Cisco's reach alone could ensure OpFlex's dominance, but it is still relatively new and as such is going up against alternatives that have been out in the open for years.
The takeaway: OpFlex is a policy protocol that serves as the foundation for Cisco's Application Centric Infrastructure. Unlike OpenFlow-based SDN, ACI is built on the idea of intelligence being built into devices that can exchange policy with, and enforce policy on behalf of, a policy manager. OpFlex utilizes a declarative, rather than imperative, model for control of network forwarding. Cisco has submitted the OpFlex protocol to the IETF and OpenDaylight as it aims to make OpFlex a widely utilized networking standard and alternative to OpenFlow.