Opflex: Cisco Flexing its SDN Open Credentials [End of Life]

There has been a lot of buzz this past few month about OpFlex. As an avid weight lifter, it sounded to me like Cisco was branching out into fitness products with its Internet of Things marketing drive. But nope...OpFlex is actually a new policy protocol for its Application Centric Infrastructure (ACI) architecture.

Just as Cisco engineered its own SDN implementation with ACI and the Application Policy Infrastructure Controller (APIC), it engineered Opflex as its Open SouthBound protocol in order to relay in XML or JSON the application policy from a network policy controller like the APIC to any End Points such as switches, hypervisors and Application Delivery Controllers (ADC). It is important to note that Cisco is pushing OpFlex an as a standard in the IETF forum in partnership with Microsoft, IBM, Redhat, F5, Canonical and Citrix. Cisco is also contributing to the OpenDayLight project by delivering a completely open-sourced OpFlex architecture for the APIC and other SDN controllers with the OpenDayLight Group (ODL) Group Policy plugin. Simply put, this ODL group policy would just state the application policy intent instead of comunication every policy implementation details and commands.

Quoting the IETF Draft:

The OpFlex architecture provides a distributed control system based on a declarative policy information model. The policies are defined at a logically centralized policy repository (PR) and enforced within a set of distributed policy elements (PE). The PR communicates with the subordinate PEs using the OpFlex Control protocol. This protocol allows for bidirectional communication of policy, events, statistics, and faults. This document defines the OpFlex Control Protocol. "

This was a smart move from Cisco to silence its competitors labelling its ACI SDN architecture as another closed and proprietary architecture. The APIC actually exposes its NorthBound interfaces with Open APIs for Orchestrators such as OpenStack and Applications. The APIC also supports plugins for other open protocols such as JSON and Python. However, the APIC pushes its application policy SouthBound to the ACI fabric End Points via a device package. Cisco affirms the openness of the device package as it is composed of files written with open languages such as XML and python which can be programmed by anyone. As discussed in my previous ACI blogs, the APIC pushes the Application Network Profile and its policy to the F5 Synthesis Fabric and its Big-IP devices via an F5 device package. This worked well for F5 as it allowed it to preserve its Synthesis fabric programmable model with iApps/iRules and the richness of its L4-L7 features.

SDN controllers have been using OpenFlow and OVSDB as open SouthBound protocols to push the controller policy unto the network devices.OpenFlow and OVSDB are IETF standards and supports the OpenDayLight project as a SouthBound interfaces. However, OpenFlow has been targeting L2 and L3 flow programmability which has limited its use case for L4-L7 network service insertion with SDN controllers. OpenFlow and OVSDB are used by Cisco ACI's nemesis.. VMware NSX. OpenFlow is used for flow programmability and OVSDB for device configuration.

One of the big difference between OpFlex and OpenFlow lies with their respective SDN model. Opflex uses a Declarative SDN model while OpenFlow uses an Imperative SDN model. As the name entails, an OpenFlow SDN controller takes a dictatorial approach with a centralized controller (or clustered controllers) by delivering downstream detailed and complex instructions to the network devices control plane in order to show them how to deploy the application policy unto their dataplane. With OpFlex, the APIC or network policy controller take a more collaborative approach by distributing the intelligence to the network devices. The APIC declares its intent via its defined application policy and relays the instructions downstream to the network devices while trusting them to deploy the application policy requirements unto their dataplane based on their control plane intelligence. 

With Opflex declarative model, the network devices are co-operators with the APIC by retaining control of their control plane while with OpenFlow and the SDN imperative model, the network devices will be mere extensions of the SDN controller. According to Cisco, there are merits with OpFlex and its declarative model:

1- The APIC declarative model would be more redundant and less dependent on the APIC availability as an APIC or APIC cluster failure will not impact the ACI switch fabric operation. Traffic will still be forwarded and F5 L4-L7 services applied until the APIC comes back online and a new application policy is pushed. In the event that an OpenFlow SDN controller and controller cluster was to fail, the network will no longer be able to forward traffic and apply services based on the application policy requirement.

2- A declarative model would be a more scalable and distributed architecture as it allows the network devices to determine the method to implement the application policy and extend of the list of its supported features without requiring additional resources from the controller.

On a light note, it is good to assume that the rise of the planet of network devices against their SDN controller Overlords is not likely to happen any time soon and that the controller instructions will be implemented in both instances in order to meet the application policy requirements. Ultimately, this is not an OpFlex vs OpenFlow battle and the choice between OpenFlow and OpFlex protocols will be in the hands of customers and their application policies. We all just need to keep in mind that the goal of SDN is to keep a centralized and open control plane to deploy applications.

F5 welcomes OpFlex and is working to implement it as an agent for its Big-IP physical and virtual devices. With OpFlex, the F5 Big-IP physical or virtual devices will be responsible for the implementation of the L4-L7 network services defined by the APIC Application Network Profile unto the ACI switch fabric. The OpFlex protocol will enable F5 to extend its Synthesis Stateful L4-L7 fabric architecture to the Cisco ACI Stateless network fabric.

 To Quote Soni Jiandani, a founding member of Cisco ACI:

The declarative model assumes the controller is not the centralized brain of the entire system. It assumes the centralized policy manager will help you in the definition of policy, then push out the intelligence to the edges of the network and within the infrastructure so you can continue to innovate at the endpoint. Let’s take an example. If I am an F5 or a Citrix or a Palo Alto Networks or a hypervisor company, I want to continue to add value. I don’t want a centralized controller to limit innovation at the endpoint. So a declarative model basically says that, using a centralized policy controller, you can define the policy centrally and push it out and the endpoint will have the intelligence to abide by that policy. They don’t become dumb devices that stop functioning the normal way because the intelligence solely resides in the controller.