Be The Steamroller Not The Road

Be The Steamroller Not The Road

Change2

Be The Steamroller Not The Road

“Once a new technology rolls over you, if you’re not part of the steamroller, you’re part of the road.” – -Stewart Brand
I always chuckle when I hear SDN or OpenFlow “bigots”. I find that it is normally vendors being flippant towards SDN in general are from a handful of camps:


  • Incumbent vendors, realizing the days of high profit margins, through vertical integration on commodity silicon are coming to an end.
  • Companies who think proprietary southbound protocols is a good place to try and differentiate. The irony is, most of those are doing flow based forwarding with proprietary messaging protocols. Net is, the same flexibility and maybe even better than OF, but using closed wire protocols. So it makes sense, of course they trash OF because they want to separate themselves using the same concepts and be the “innovator”. I personally think the application layer is the place to focus to be effective. I am expecting Intel to own the edge hardware market someday, but thats for another day.
  • Then there is the a-typical IT guy, that hates change. Hey, thats understandable. I like stability as much as the next fear of failure driven person. Server guys freaked out over server virtualization, mainframe guys hugged their water cooled monoliths all the way to the dumpster, but at the end of the day, IT abstraction doesn’t shrink jobs. Horizontalization creates jobs and enables innovation.

When people spend time to understand that OpenFlow is merely an open messaging protocol to instantiate flow based forwarding. Flow based forwarding integrates L4 into forwarding decisions. L4 adds rudimentary application awareness. OpenFlow is merely a means of forwarding L1-L4 in a single protocol. Thats not to say you don’t need other protocols. OpenFlow has no awareness of port provisioning etc. That leaves plenty of room for differentiation in the management plane and actually building applications to control the network. Odds are, one vendors SDN solution isn’t much different from the next when you look under the hood. Outside of performance, look for application differentiation, not who has the best flow-based forwarding protocol.

SDN in the Data Center and Service Provider

A vendor agnostic southbound forwarding abstraction is all OpenFlow is. Creating network operating systems and extracting state to run programs against is much more interesting but we don’t get there without a few key protocols.


“The people who resist change will be confronted by the growing number of people who see that better ways…are available thanks to technology.” – -Bill Gates So be open minded, understand most of us don’t care wether it is OpenFlow or not, but we also don’t want to wait around for another 6,000 RFCs and a dozen more consortiums (which I happen to be encouraged by OMG and Daylight) to define something everyone unanimously agrees is a flawless abstraction. The good news is, the consumers will consolidate with or without consensus from product managers. If it isn’t OpenFlow for flow based forwarding, pick something else, just pick something. So for my fellow biggots, that still remember what they learned in computer science 101, that layered abstractions hide irrelevant details to manage complexity, I salute you. We want applications to efficiently control the network, not the best mousetrap.

About the Author

Brent SalisburyI have over 20 years of experience wearing various hats from, network engineer, architect, ops and software engineer. More at Brent's LinkedInView all posts by Brent Salisbury →