There has been a flurry of press around Cisco’s release of OpFlex. If you want the nitty gritty details, please read the IETF draft available here. What exactly is OpFlex? The IETF draft sums it up nicely:

It’s clear that Cisco intends to make OpFlex an open standard together with it’s partners in the vendor, provider and Open Source communities. We’re working hard to make that a reality. On the Open Source front, I’m leading a team of people who are working hard on the code around this new OpFlex Policy Agent. We intend to fully Open Source the OpFlex Policy Agent under the Apache 2.0 license. We’re excited to build an Open Community around this work, and in the coming months we’ll be looking to get more companies and individuals involved as we move this out into the Open. As you can imagine, starting an Open Source project from scratch takes time and planning, and we’re doing our best on all of these fronts.

What Exactly Is OpFlex?⌗

So, now that you know what OpFlex is, what exactly is it not? Well, if you’ve read the article here, you may think it’s a, quote, “OpenFlow Killer.” Well a headline such as this may make for good SEO, it’s not true. OpFlex is meant to be embedded in the device or host via the Policy Agent. This could be a virtual switch such as Open vSwitch, a whitebox switch, a load balancer, a firewall, or any other element which can enforce policy. To show how this all fits together, the following diagram can be used:

As you can see from the diagram, the key pieces of OpFlex are the Policy Authority and the Policy Agent. Policies defined in the Policy Authority are resolved asynchronously by the Policy Agent. The policies are then rendered in the system specific implementation into the programmability functions provided by the device or system. Examples of programmability functions could be the OpenFlow and OVSDB protocols supported by Open vSwitch, APIs provided by Arista’s EOS, the onePK APIs supported on Cisco gear, or even a CLI interface to a firewall device. OpFlex doesn’t replace the programmability mechanisms provided by the system, it works in tandem with them to enforce the policy. This is the key piece which many have missed.

In Conclusion⌗

We’re excited about the potential of OpFlex and the Policy Agent. OpFlex is not meant to replace Open vSwitch, nor any other host or system programmability layer. Open vSwitch is a great Open Source project for which Cisco is a contributor. We plan to continue working closely with the Open vSwitch community, as well as projects such as OpenCompute, OpenDaylight, and the ONF. And just as these are all vibrant Open Source projects and communities, we hope to get the OpFlex Policy Agent into a similar state over the coming months and build a community for people who want to enable Open Source policy.