Opflex: Cisco Flexing its SDN Open Credentials [End of Life]
The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life. The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’. Visit https://f5.com/cisco for updated information on the integration. 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 JSONthe 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 fabricarchitecture 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.
OpFlex, OpenDaylight and OpenStack: Policy-Driven Networking
#OpFlex #CLUS #OpenDaylight #OpenStack #F5 There's multiple moving parts to driving a policy-driven network There's a lot of buzz about Cisco's proposed standard, OpFlex, as a control protocol for policy-driven networks. The protocol addresses, in part, the inability of protocols like OpenFlow to provide a means by which L4-7 services can be consistently provisioned and configured (and updated dynamically) as part of a comprehensive approach to modern network architecture. For some of us, this the culmination of efforts now long in past (because five or six years ago is forever in technology time) to drive toward a singular means of integrating infrastructure to enable an agile network capable of scaling and adapting to meet the challenges of an increasingly cloudy, virtualized application world. Long time readers may recall this blast from the past: Somehow the network-centric standards that might evolve from a push to a more agile infrastructure must broaden their focus and consider how an application might integrate with such standards or what information they might provide as part of this dynamic feedback loop that will drive a more agile infrastructure. Any such standard emerging upon which Infrastructure 2.0 is built must somehow be accessible and developer-friendly and take into consideration application-specific resources as well as network-resources, and provide a standard means by which information about the application that can drive the infrastructure to adapt to its unique needs can be shared. -- Infrastructure 2.0: The Feedback Loop Must Include Applications Suffice to say that the need for a standardized, southbound (if we want to use today's terminology) protocol has long been recognized as foundational for a next generation network architecture. But a standardized southbound protocol isn't the only piece of the puzzle. A control protocol only specifies how information is to be exchanged. It does not necessarily specify what that information is. OpFlex is a control protocol that describes how policies are to be exchanged and updated (and the relationship between a variety of policy-related components), but it does not specify what those policies will look like. Probably because, well, where do you start? How do you standardize a policy across disparate implementations even within a specific "category" of infrastructure? Should policy describe services (load balancing, application acceleration) or discrete device elements (ADC, IPS, SWG)? Therein lies the real challenge; a challenge we've (the industry) been struggling with for a long, long time: ...none of us are really compatible with the other in terms of methodology. The way in which we, for example, represent a pool or a VIP (Virtual IP address), or a VLAN (Virtual LAN) is not the same way Ciscoor Citrix or Juniper represent the same network objects. Indeed, our terminology may even be different; we use pool, other ADC vendors use "farm" or "cluster" to represent the same concept. Add virtualization to the mix and yet another set of terms is added to the mix, often conflicting with those used by network infrastructure vendors. "Virtual server" means something completely different when used by an application delivery vendor than it does when used by a virtualization vendor like VMWare or Microsoft. And the same tasks must be accomplished regardless of which piece of the infrastructure is being configured. VLANs, IP addresses, gateway, routes, pools, nodes, and other common infrastructure objects must be managed and configured across a variety of implementations. -- Making Infrastructure 2.0 reality may require new standards One of the reasons OpenFlow was not universally lauded by providers of L4-7 services is that OpenFlow by design was focused on stateless L2-3 networking, pushing rules for port forwarding and routing that controlled the network fabric. While certainly L4-7 services must interact and interoperate with L2-3 by virtue of their placement in data center architectures in the network, their primary operation is at the application layers. The rules and policies used to implement load balancing are not just about forwarding to an IP address and a port, but about how such decisions should be made. The rules and polices that protect applications from myriad application attacks must include URLs and actions to be taken at the application layer - including those that might require rewriting the payload (message) being transmitted. These rules and policies are not only specific to the category of service (web application firewall, web anti-fraud, web acceleration, caching) but to the specific implementation (i.e. the product). That makes defining a singular "god policy" for L4-7 similar to that of OpenFlow is not only impractical but downright impossible without stripping those services of their usefulness. Thus, some other approach was necessary. For that approach, we need to look to the OpenDaylight (ODL) project. The OpenDaylight Connection So ODL has created a new project called the ODL Group Policy plug-in. As explained by Cisco in an OpFlex white paper, "the goal of this project is to provide a policy-based API that can serve, in practice, as a standard information model in OpFlex implementations." The ODL Group Policy PlugIn "introduces the notion of groups of endpoints and policy abstractions that govern communication between these groups. The goal is to support a northbound API that accepts abstract policy based on application requirements while offering numerous concrete southbound implementations for programming network element with configuration/programming stanzas rendered from application policies." Translated into regular old English, what it means is that instead of a policy that's essentially a bunch of ACLs and routing and switching entries, it's designed to be more developer and human friendly. So you might say "Web server A can speak SQL to Database server 1" or "Let the OpenStack console communicate with App Server B". An imperative policy would spell out the VLAN participation and routing, and the ACLs required to allow traffic between the various VLANs, IP addresses and ports. It would be long and prone to misconfiguration simply due to the number of commands required. A declarative policy just describes what is desired, while allowing each individual network device - a policy element in an OpFlex architecture - translate that into the specific commands and configuration required for its particular role in the policy domain within which it is acting. This reduces the possibility of misconfiguration because, well, no configuration specific commands are being communicated. It also addresses the problem above noted with defining common object models across a role in the network, particularly for those devices operating at L4-7. Traditional approaches have relied on finding the lowest common model, which inevitably ended up with all offerings needing to dumb down (commoditize) their value in order to ensure consistent support for all "XYZs". By abstracting to the policy - and not the object model - level, the OpFlex approach effectively eliminates this issue and emphasizes defining what is desired by the application, but not how. Now, the actual policy declaration is unlikely to take the form of natural language (that'd be nice, but we're not quite ready for that... yet) but the general premise is to provide a far more, shall we say, friendly policy language. The OpenStack Connection Astute readers will note that OpenStack was mentioned but not further explored as of yet. Right now there's very little on the connection between OpenStack and OpFlex and OpenDaylight, but there are mentions that make it clear that OpenStack is not being shunned with these efforts. The Group Policy Plugin proposal specifically calls out OpenStack Neutron considerations: Relationship with OpenStack/Neutron Policy Model The model developed within this project relates to that being developed in OpenStack in the following ways: The Neutron model being developed MUST be always renderable into the OpenDaylight policy model. The OpenDaylight model MUST NOT be constrained in any way by the Neutron model being developed. Given that OpenDaylight's focus is operationalizing the network, and OpenStack's focus is operationalizing the entire infrastructure stack (compute, network and storage), one can see that a relationship makes a lot of sense. A comprehensive approach might be to "plug in" OpenDaylight by accepting through its policy API a Neutron policy and distributing that to both policy elements via OpFlex as well as through OpenFlow to OpenFlow-enabled network elements. Enabling Choice One of the side effects - or perhaps intentional outcomes - of OpFlex and a policy-driven model is that it enables organizations to choose their preferred implementation model. Because OpFlex is designed to be one of the southbound API options for SDN implementations like OpenDaylight, it allows organizations to choose that model without compromising on support for a wide variety of network options. OpFlex and OpenFlow could, theoretically, coexist in such a model, or support an OpFlex-only model. Too, the desire to not impair (or be impaired by) OpenStack means there's a movement toward cooperation between these various open source networking projects. The view of the open source movement has always been free, as in choice (and not necessarily gratis) and these developments and approaches certainly embody that view. These are still early days, despite the increasing maturity of OpenStack and continued momentum behind SDN. But the interaction and cooperation required to produce interoperability of policy and operational frameworks across these three efforts is definitely promising.
