OpFlex, Standards-Based Protocols, and Cisco’s Messaging Problem

On April second, Cisco introduced something that seems to make a lot of sense in its new declarative-based, ACI-led world of software-defined networking: a policy mechanism. The blog post about it was pretty straightforward: it included the obligatory nods toward the Internet Engineering Task Force (IETF) and open-source communities, defined the differences between the traditional imperative and the newer Cisco declarative models, and had snazzy graphics. Cisco laid out the core challenge clearly:

For this declarative model to work across a multi-vendor environment, to translate and map policy definition into the infrastructure, there has hitherto been no standard protocol to do that across physical/virtual switches, routers and L4-L7 network services. This vacuum has led to the development of OpFlex, a new open standard recently submitted to the IETF.

Pretty simple, right? The IETF draft is similarly straightforward (which, most of you will know, isn’t always the case), with a reasonable scope, pretty good descriptions of the logical components, and ample JSON and RPC documentation and examples. In fact, it’s remarkable primarily for how boring and uncontroversial it is.

Finally, as with most Cisco announcements these days, it had a long list of logos that are set to support, contribute to, or incorporate the technology. Again, no surprises here, with the usual group of collaborators like Microsoft, IBM, F5, Citrix, and Red Hat mentioned prominently, and the usual group of competitors like VMware, Arista, Brocade, and Juniper not mentioned at all.

So, I ask this question: If the technology being introduced is so logical, and if the announcement and IETF draft are so straightforward, and the group of collaborators is so unremarkable, why has Cisco met with so many negative reactions?

Here are some examples:

• “Cisco reveals OpenFlow SDN killer,” Jim Duffy, Network World
  • Mr. Duffy’s track record is such that his handling of the story and the quotes he obtained from various people shouldn’t be a surprise, but it sure set off a public firestorm on social media. Happily, in the end Mr. Duffy agreed to research stories before publishing them, as long as Cisco aligns its messaging better.
    • “In essence, Cisco is re-inventing the OpenFlow wheel, proposing a new protocol where one already exists, though its objective is different.”
    • “Cisco and industry partners are all contributing to this release, and OpenDaylight will ensure an ‘open’ approach and transparency to Cisco’s policy-based technology, Cisco says. Still, observers note a not-so-subtle Cisco bend in the direction OpenDaylight is taking.”
• “Who’s up for yet another software-defined net protocol? Cisco wants to see some hands,” Jack Clark, The Register
  • The Register is well known for snappy headlines and snarky commentary, but it takes some pointed shots at this announcement:
    • “Cisco has unveiled an openly defined protocol for controlling network hardware, but it lacks an essential ingredient: participation from other network hardware makers.”
    • “At launch neither Juniper nor Brocade nor Arista Networks are involved in the protocol, making Cisco’s claims of openness seem rather fantastic.”
    • “Open-source software using OpFlex will be developed and promoted by OpenDayLight—a software-defined networking project that sparked controversy last year when it plumped for Cisco’s proprietary tech as its main component, causing a walkout by pro-open-source startup Big Switch Networks.”
    • “The response by Cisco to this has been a series of releases that emphasize new degrees of openness in its technology while subtly preferring underlying Cisco hardware. The more things change the more they stay the same, and so on.”
• “Cisco Counters OpenFlow SDN With OpFlex, Updates Nexus Switches,” Timothy Prickett Morgan, EnterpriseTech
  • This article reads as more of a regurgitation of the press releases that Cisco put out, but even here there’s a zinger at Cisco’s expense:
    • “And, as you might expect, with that new switching hardware comes a new protocol, called OpFlex, which Cisco divulged at the Interop conference this week.”

So, what does this mean? In my opinion, Cisco has a number of issues, some more significant than others, that are highlighted by what should otherwise be a mundane announcement:

1. Its sway over the standards bodies may be slipping.
2. Its time-tested method of using its ecosystem to push a de facto protocol while the ratification process happens and then incorporating the standards into its protocol isn’t as easy in an open, interoperable world.
3. There is general skepticism about its role in the OpenDaylight project or, more specifically, about the independence of the project itself. As such, using that vehicle to foster community involvement and openness doesn’t have the effect Cisco would like.
4. There is, generally, a disconnect in the messaging that the field-facing experts and the analyst-facing marketing teams are putting into the market.

Of these four, Cisco should be most worried about the first two, which are related to one another. If you look back over Cisco’s run of dominance in the networking market, there have been numerous instances where a draft of a protocol has been submitted by a group, and while that sometimes arduous process has worked itself out, Cisco has jumped into the market first with a proprietary protocol of its own design. Once the ratification happens, Cisco usually makes sure to incorporate all of the included features, but it reaps the benefits of the first mover advantage by leveraging its ecosystem clout. Zeus Kerravala does a good job listing some examples of this tactic, referencing Power over Ethernet (PoE) and Enhanced Interior Gateway Routing Protocol (EIGRP), but we could add Fibre Channel over Ethernet (FCoE) and others to the list as well. Generally, this has been a positive thing for Cisco and its customers, albeit to the consternation of competitors and companies looking for guaranteed interoperability.

Being able to succeed with this tactic also requires a firm hold on the ratification process and the standards bodies themselves. In the past, Cisco has been a master of this, and it has been prominently involved in most of the significant standards that have been introduced. Indeed, pushing a “standard” that didn’t include Cisco was often futile, since its stranglehold on particular product lines meant it could strangle such challenges early.

Recently, however, we’ve seen cracks in both of these areas. A great example is the “Valentine’s Day Draft” introduced by VMware, Microsoft, Red Hat, and Intel—an IETF draft that Cisco wasn’t involved in at all. Acting as a super-set for all of the currently used tunneling protocols (specifically VXLAN, NVGRE, and STT), this protocol, named “Geneve,” could be a very big deal in any SDN implementation that needs overlays (i.e., all of them). If this had happened a decade ago, Cisco would have announced that VXLAN was the existing standard that it was going to support, and it would have hinted broadly that its ASIC wasn’t going to support on-chip acceleration of the new tunneling protocol. The result would have been that Geneve would have died a slow death as competing vendors backed away from it, knowing that the majority of the customers out there wouldn’t be able to take advantage of it using their legacy Cisco gear.

Today, however, it seems like the opposite is true: not only is a protocol like Geneve being conceived and submitted without Cisco, but it appears to be gaining momentum because Cisco isn’t involved. The real danger is if something of this magnitude gets ratified by an IETF body that Cisco doesn’t have sway over, and all of a sudden all of those shiny new APIC-enabled Nexus switches don’t work with a protocol supported by the largest virtualization vendors on the planet (VMware, Microsoft, and Red Hat) and the network device arms dealer (Intel). In that case, customers will have to re-evaluate Cisco’s claims of “better SDN through integrated hardware” and decide whether they are willing to pay that premium any longer. Make no mistake: this would be a disaster situation for Cisco and its business model.

Another objection that comes up repeatedly, and was noted in two of the articles I cited above, is the involvement of the OpenDaylight project with regard to Cisco’s SDN strategy. Knowing what I know about the project and the people involved, I think it’s one of the smartest things Cisco has done in a long time with respect to open source. I’m sure there are politics, and I’m confident there are people within the Cisco leadership who have no idea what it means or how it works, but it’s given them credibility where there was none, it’s helped them learn how the open-source community works and what it responds to (positively and negatively), and it’s done so in an area in which Cisco has expertise and which is also a place where OpenStack needs as much help as possible (with regard to networking). The rub is that most of the traditional tech press doesn’t have any idea how open-source foundations and projects work, either, so no matter what the backstory or truth really is, OpenDaylight becomes an easy way to take cheap shots at Cisco.

Finally, the observation that Jim Duffy makes about the differences in messaging coming from different parts of the company is very valid. I have no idea what information was given to the press prior to the launch, and I have no idea who presented it, but I’m confident the content wasn’t nearly as good, or the presenter nearly as competent, as Kyle Mestery and his post on his blog in response to Mr. Duffy’s article. It’s fair to say that as the networking world gets more abstracted and moves further away from the traditional “core, distribution, access” model, vendors are going to have to rely less and less on the ability of the tech press to digest a product message and put it out with relevant context. Cisco would do well to identify the people who have relationships with the community and an ability to provide great messaging and context, and to leverage those people more as primary sources.

Indeed, VMware has known this fact for years, since running into the same issue regarding server virtualization, and it has been spreading the word about its SDN focus by throwing some of the most respected names in the community at the problem. The blog posts put out by Brad Hedlund in particular have been excellent at bridging the gap for both customers and the industry between the existing networking constructs and the VMware vision of the SDN future. Of course, they take a very VMware-centric view of the industry, but that’s the point.

Without that kind of focus and communication, it becomes hard to get the entire story across, and when that happens you lose control of the narrative, no matter what your traditional place in the market has been. It’s disruption at its finest, and it’s something that has been dogging Cisco since before VMware ever started talking about the acquisition of Nicira. Cisco needs to find a way to get that narrative back.

Personally, I’m fine with OpFlex. It will be good for customers who choose the Cisco model, and since the battlefield is quickly moving up the stack into the policy management space, this is table stakes for Cisco to have a seat at the table. Unfortunately, the tech seems to matter little to the Cisco critics these days, and they have no one to blame but themselves.

Photo Credits:

• Photodisc/Photodisc/Getty Images
• Stack Exchange