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:

1. The Neutron model being developed MUST be always renderable into the OpenDaylight policy model.
2. 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.