Thoughts on Cisco’s OpenFlow Conversion

It has not been easy finding time to write this past week. In addition to work and other demands on my time, I had been suffering from a blockage in my ear that impaired my hearing, upset my balance, and generally annoyed the hell out of me.  That problem has been resolved, and I’m back to being as normal as I get.

Ensconced at the keyboard once again, however, I found myself suffering from writer’s block after having rid myself of ear block. So, I consulted the Idea Generator on my iPhone, and it offered this troika for inspiration: “narcotic neon coat.” I gave that trio of words due consideration, then I decided to write about OpenFlow. Trust me, it’s really for the best.

More than OpenFlow

Some of you might contend that OpenFlow has received too much attention. That’s fair, I suppose, but value judgements about whether a topic has gotten too little, too much, or just enough attention are subjective, and also subject to changing circumstances.

Others might argue that software-defined networking encompasses more than OpenFlow. If that’s your claim, you’d be right. OpenFlow is just one mechanism or means of realizing a software-defined network. There are other ways to get it done, standards-based and proprietary. That said, OpenFlow has major industry backers and momentum, it’s becoming inextricably linked with SDN, and it’s been reluctant to surrender the spotlight.

No matter how you slice it, this was a big week for SDN and for OpenFlow. At Stanford University, the Open Networking Summit was in full swing, dedicated to discourse on SDNs and how they could be realized with OpenFlow.

Crowded at the Summit

I wasn’t there, but many were. More than 600 people applied to attend the summit, but only 350 could be accommodate by organizers, who now have decided to hold the next instance of the event in April rather than waiting a full year until the following October.

Notwithstanding the hype, then, Open Flow has emerged as a networking topic for all seasons. Certainly the great and the good of the networking industry would seem to agree. Cisco Systems was well represented at the summit, and Cisco got out the message that it is a believer in SDN and plans to support OpenFlow on its Nexus switches, starting with the low-latency Nexus 3000 line. A specific timetable hasn’t been provided. (Or, if it has, I haven’t seen it.)

Cisco: SDN Next Evolution of Networking

In a Cisco blog post penned by Omar Sultan, David Meyer, a Cisco distinguished engineer (as opposed to the undistinguished ones), had the following to say about why Cisco, in supporting OpenFlow, has made what many might interpret as a counterintuitive move:

“. . . . Cisco had always embraced disruption–we don’t always get it right on the first shot, but we usually get it in the end.  Take server virtualization as an example–while we may not have been first off the line, we now have the broadest and strongest portfolio of virtualization networking technologies in the market.  Critics only saw the short-term impact to our switching revenue (less ports sold) but we saw the transformational value of virtualization. We see SDN in a similar light–as the next evolution of networking and we see OF as an excellent mechanism to drive maturation of both the technology and the underlying thinking.”

That last sentence is commendable for its clarity and transparency and it bears further inspection. Cisco sees SDN as the next evolution in networking, and it perceives OpenFlow as “an excellent mechanism to drive maturation of both the technology and the underlying thinking.”

OpenFlow if Necessary, But Not Necessarily OpenFlow

Now I will foul the waters with my interpretation of what it signifies, beyond the obvious. By necessity, I will veer into the murky shallows of speculation and ambiguity, because — until Cisco provides further elaboration — we won’t know, at least for now, how Cisco ultimately will play its SDN cards. (Yes, I mixed metaphors in that last sentence. So shoot me — but only figuratively).

My take, which might be worth the proverbial two cents, is that Cisco is all in on SDN. As for OpenFlow, I think Cisco is less enamored.  I read Meyer’s and Cisco’s comments and I get the feeling Cisco is saying that it will support OpenFlow as an SDN mechanism if necessary, but not necessarily OpenFlow as its preferred SDN mechanism. Meyer says Open Flow can drive maturation of SDN technology and thinking, but he hasn’t said that it ultimately will be the only means, or event Cisco’s preferred means, of achieving SDN.

I know that others, including Craig Matsumoto of Light Reading, see a close conjoining of SDN and OpenFlow in Cisco’s positioning. I respectfully disagree, though I could, as always (does it even bear saying?), be wrong.

Diverged Business Interests of ONF’s Board and Networking Vendors

Matsumoto has posited that OpenFlow is looking less like a threat to Cisco’s and its business model. At this point, it’s still hard to say, but I think Cisco would suffer materially in the long run if OpenFlow matures as the Open Networking Foundation’s six founding board members — which include carriers and large cloud service providers such as Deutsche Telekom, Verizon, Facebook, Google, Microsoft, and Yahoo — would like it to do, and if the public cloud fulfills the bulk of its commercial promise.

Further, I think the goal of the the ONF Founding Six is completely virtualized infrastructure (compute, storage, networking) run on wall-to-wall, bare-bones hardware, overseen by a management layer of software and driven by applications and services. This would bring lower capital expenditures for gear, and reduced operational expenditures for network management.

I realize there’s been a search for OpenFlow’s killer app — and that search should continue, obviously — but the founders of ONF seem to be focused primarily on cost savings. For them, it’s not about doing something strikingly new or revolutionary, but about getting more from less, and for less. In that context, OpenFlow makes sense — at least for them — as it delivers quantifiable business benefits that they have not been able to derive from current network infrastructure.

In the Enterprise, A Different Story

Of course, what the ONF founders want might not be what enterprise IT buyers need. There’s an opening here for Cisco, for HP Networking, for Juniper, for Arista Networks, and for all the other networking vendors to define SDN in ways that are more amenable to those enterprise buyers across a wide range of horizontal and vertical markets.

If all else fails, though, and OpenFlow becomes an SDN juggernaut, there’s always recourse to “embrace and extend,” particularly at the management layer. It’s not as though vendors haven’t cracked open that chestnut before.

About these ads

3 responses to “Thoughts on Cisco’s OpenFlow Conversion

  1. Pingback: OpenStack における SDN コネクションを探求する _2 [ #cloud #cloudcomputing #jazug #jawsug #googlejp #opencloudjp #cbajp ] « Agile Cat — in the cloud

  2. Pingback: New Spin-In Called Insiemi: A Framing Exercise « SIWDT

  3. anyone remember that Cisco was actually born out of a Stanford experiment? that Prof NMcK has been a long time comnsultant to many, many Cisco resrach initiatives? Come on. Craig Matsumoto has got it pegged.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s