New Details about Cisco ACI: OpFlex

Author
Peter Welcher
Architect, Operations Technical Advisor

Recently, Cisco generously provided a briefing to the CiscoChampions, updating the group with new details about Cisco ACI. The presentation was NDA until April 2, I presume coordinated with announcements to be made at InterOp. The biggest new item I noticed was OpFlex. I’ll tell you what I know about OpFlex below, somewhat below the tantalizing diagram. I’ll be posting this quickly in the morning, then off to various tasks. When I can, I’ll look at any announcements and apply corrections if necessary.

 

The CiscoChampions ACI update session started with a review of ACI policy, End Point Groups, etc. See my and other prior blogs, also recent CiscoLive presentations (links below).

If you’ve been paying attention, the Nexus 9K line is attractive for its cost effective 40 G ports, leapfrogging the 10 G generation of switches. Cisco partners are being incentivized to sell N9K as well. Cisco claims over 800 customers already for the Nexus 9K line, first announced in November of 2013. They run a cut-down version of NX-OS. See my prior blog What Features Does the Nexus 9K Support? for the features supported by the Nexus 9K right now.

Cisco is announcing the 9504, a smaller-sized Nexus 9500, shipping now. You’ve no doubt noticed the recent mentions of the large 9516 as well!

For what it’s worth, I personally somewhat expected ACI to be a big datacenter play, due to integration, early complexity, and relative value of automation. Somewhat to my surprise, I’m seeing smaller organizations are also interested. The agility, automation, doing more with less staff, and policy control all are getting favorable reception. I do strongly think such organizations are not going to know how to hire appropriate programmers, nor are they going to want to manage or support script development — a canned offering will be key to such customers.

Cisco also talked about the rather large Nexus product line, and positioning. They are becoming orientated towards use cases, and with such a large portfolio, there is at present some overlap. See also my prior blog. Nexus: What Goes Where

I see this as coming down to ports / speeds / costs plust “NX-OS with features”, DFA capable devices, or “vanilla NX-OS” with future ACI capability. (Still due second quarter of 2014.)

We were given a fairly lengthy demo of the ACI GUI, considering the 2 hours available. The presenters emphasized the GUI is like to change in appearance, so I’m not going to post screen captures. One note-worthy point was that the objects in ACI are to be exposed for consumption equally via GUI, API, CLI, and even Linux shell file system representation of objects. You can cd to a directory, vi a file, and save and the changes will automatically propagate. Not that doing so is the most efficient way of doing so.

OpFlex

Then we get to the New! Cisco is providing an open Southbound API for ACI. It is to be called OpFlex. As with most Cisco announcements recently, the ecosystems part is huge, including partners such as: Citrix, Embrane, F5, IBM, Microsoft, RedHat, SourceFire, Canonical. (Note who is not on that list!)

By the way, googling “Cisco OpFlex” reveals that there have been a couple of prior mentions, and some recent discussion.

OpFlex will come with an open source embeddable agent. It will peer with the ACI fabric and exchange policy. Cisco is proposing an open standard to provide investment protection. (Hence announcement at InterOp, and an RFC to be published at/around the time of the announcement.) OpFlex will come with an open agent for Open vSwitch (OVS), an ODL component, intended to be re-usable across device, i.e. a reference for porting code to other platforms.

The presenter discussed imperative control, where explicit orders must be given, and contrasted that to declarative control, where you set policy. The analogy provided was baggage handlers (read baggage label, place it on right belt) versus air traffic control (tell plane the runway and what to do, but not the details of how to do it). The point being that simpler interoperability requires abstract policies passed down to intelligent devices, with the policy endpoing then mapping the policy to the hardware.

One use case for this is for virtual switch integration with hypervisors, deploying policy across multiple hypervisors simultaneously. (Is this Cisco positioning ACI as a “meta-hypervisor”?)

Is ACI being positioned as a “meta-hypervisor”?

(Not to mention “InterCloud”?)

OpFlex also gives ACI a way to exchange policy with L4-L7 devices.

ACI gives vendors the ability to write device packages, as Cisco has previously discussed. By doing so, users can upload a script to ACI from the vendor, allowing direct calls to the vendor API. The vendor can leverage OpFlex as well.

Related Links

(There are more Practical SDN blogs listed at the beginning of that blog)

Hashtags: #CiscoChampion #ACI #OpFlex 

Twitter: @pjwelcher

Disclosure Statement

ccie_15years_med CiscoChampion200PX

Leave a Reply