Cisco Partners with F5 to Accelerate SDN Adoption [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. SDN, like every new technology, has begun maturing from its singular focus on standardizing networks to embrace a broader vision focused on addressing real challenges in modern data centers. SDN today aims to provide an automated, policy-driven data center capable of adapting to the rapid shifts in technology driven by cloud, mobility and massive growth in applications. Customers require a comprehensive approach to deploying applications that includes automating and orchestrating both network and application services. Realizing this vision requires programmability and choices. For over ten years F5 has been delivering both to its customers with open APIs: iRules for the data plane, iControl for the control plane and iApps to capture and apply service definition policies. Last year we introduced Synthesis, which added orchestration via BIG-IQ and extended the reach of application services into the cloud. These industry leading innovations further enabled customers with choices for application deployment and orchestration through a robust partner ecosystem. In November 2013 that ecosystem was expanded to include Cisco and its Application Centric Infrastructure (ACI). ACI addresses network challenges stemming from years of siloed network topology such as the inability to rapidly provision services and respond in real-time to conditions impacting application performance. While strides had been made to address those challenges, Cisco took a major step forward with ACI. Its focus on programmability as a way to automate and orchestrate the entire data center stack aligned well with F5’s vision and capabilities, making support for ACI a natural extension of our architecture. Partnering with F5 brings a sophisticated set of programmable L4-7 services to Cisco ACI and offers customers another choice in moving confidently toward adopting an SDN architecture that addresses the entire data center stack. Customers can choose to orchestrate F5’s catalog of L4-7 services directly through our control plane API, iControl, via our orchestration product, BIG-IQ, or through ecosystem partner orchestration systems like Cisco APIC. Once adopted, customers will be able to use Cisco ACI to orchestrate differentiated L4-7 services from F5 to address a variety of challenges and directly support business requirements related to application performance, security and reliability. Customers will be able to orchestrate L4-7 services with Cisco ACI that steer application requests based on device, user identity, location and application. Customers desiring to attach application security polices to existing applications will be able to use Cisco ACI to orchestrate insertion of the appropriate F5 services to reduce risk. This week, Cisco announced an architecture and supporting control protocol to further expand customer choices in orchestrating the data center. The OpFlex architecture is a policy-based model that centralizes control and locally enforces policies using an open southbound API – the OpFlex Control Protocol. This complements F5’s existing architectural vision and though OpFlex is still in the definition phase, F5 is committed to supporting it. F5 is delighted that this Cisco partnership offers customers expanded choices to move forward with SDN initiatives to automate and orchestrate the entire data center stack.
F5 and Cisco: Operationalizing the Network [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. #Interop #F5 #ACI #SDN #Devops #SDAS F5 believes applications are transforming business. Whether expressed through new business models, a need to deliver applications to market faster or to support the impact of new application architectures on IT, applications must also be the focus of data center infrastructures. Cisco and F5 share a common vision for solving key pain points in customer’s next generation data centers while meeting their critical data center requirements today. F5's strategy is embodied in Synthesis, Cisco in its Application Centric Infrastructure (ACI). Cisco ACI enables an infrastructure-wide programmable model based on application policies as opposed to the network-centric approaches of earlier SDN models, which aligns with F5 Synthesis' application-driven approach to deploying and delivering the critical services IT needs to align security, performance and reliability outcomes with business requirements and customer expectations. Both initiatives are focused on efficiently delivering applications by taking a programmatic approach to networking and services architectures. This approach enables organizations to realize the benefits of greater automation of on-demand IT tasks that support application deployments and meet expectations for secure, fast and reliable applications. Today, Cisco is announcing that a number of partners will participate in the ACI policy model, and key components of the ACI infrastructure completely open, allowing for greater expansion of the ecosystem, alternative solutions, accelerated innovation and greater choice for customers. Both Cisco and F5 believe that applications should be the focus of an automated, policy-based approach to data center infrastructures. We applaud Cisco’s efforts to make ACI an open architecture with standardized interfaces, reference implementations and contributions to the open source community. Cisco's decision to open OpFlex, the southbound protocol for exchanging policy with the Cisco APIC controller, through standards, open source distributions and reference implementations will accelerate customer options by enabling leading hypervisors, switches and L4-7 services to self-configure using the ACI application policy. OpFlex agents that enable devices to participate in the ACI infrastructure will be distributed by Cisco technology partners and ecosystem vendors such as Microsoft, Red Hat and F5. OpFlex will provide customers the option to integrate critical network and application services under common workflow automation and cloud orchestration tools to drive greater automation and efficiency in the data center architectures necessary to support the transformative impact of applications on today's businesses. This open approach aligns with F5's strategy of open, standards-based integration models. F5 welcomes Cisco's decision to work with OpenDaylight to create a 100% open source, ACI-compatible policy model and OpFlex reference architecture. F5 Synthesis SDAS are designed to be the stateful L4-7 services complement to stateless L2-3 networking for SDN architectures and OpenDaylight is no exception. By working to build and release ACI-compliant policy models for OpenDaylight, Cisco will enable customers who choose OpenDaylight as the foundation for their SDN architectures the ability to also take advantage of F5 SDAS to support the breadth and depth of application services needed today to deliver applications successfully. F5 is supportive of the efforts to make OpFlex a standard and to be part of the OpFlex ecosystem. We support Cisco Systems efforts to make OpFlex a standard policy language to communicate with the APIC controller and provide controller alternatives through Open Daylight.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.
