OpenFlow is like IPv6

Frequent eruptions of OpenFlow-related hype (a recent one caused by Brocade Technology Day Summit; I’m positive Interop will not lag behind) call for a continuous myth-busting efforts. Let’s start with a widely-quoted (and immediately glossed-over) fact from Professor Scott Shenker, a founding board member of the ONF: “[OpenFlow] doesn't let you do anything you couldn't do on a network before.”

To understand his statement, remember that OpenFlow is nothing more than a standardized version of communication protocol between control and data plane. It does not define a radically new architecture, it does not solve distributed or virtualized networking challenges and it does not create new APIs that the applications could use. The only thing it provides is the exchange of TCAM (flow) data between a controller and one or more switches.

Cold fusion-like claims are nothing new in the IT industry. More than a decade ago another group of people tried to persuade us that changing the network layer address length from 32 bits to 128 bits and writing it in hex instead of decimal solves global routing and multihoming and improves QoS, security and mobility. After the reality distortion field collapsed, we were left with the same set of problems exacerbated by the purist approach of the original IPv6 architects.

Learn from the past bubble bursts. Whenever someone makes an extraordinary claim about OpenFlow, remember the “it can’t do anything you couldn’t do before” fact and ask yourself:

  • Did we have a similar functionality in the past? If not, why not? Was there no need or were the vendors too lazy to implement it (don't forget they usually follow the money)?
  • Did it work? If not, why not?
  • If it did - do we really need a new technology to replace a working solution?
  • Did it get used? If not, why not? What were the roadblocks? Why would OpenFlow remove them?

Repeat this exercise regularly and you’ll probably discover the new emperor’s clothes aren’t nearly as shiny as some people would make you believe.

1 comment:

  1. I like! Agree re OpenFlow and newness. Also the IPv6 purists comment. (And WHY is using ICMP as a larger part of the protocol a good idea, when MTU issues and ICMP-based DDOS have been a problem for IPv4 for years? Also who had the bright idea that anyone in their right mind would only have one upstream ISP, thus from one perspective creating the whole shim6 / LISP set of efforts?)

    Just ran across the fact that the Cisco IPv6 implementation does subnet bits not wildcard masks in ACL's for IPv6. This means if you use some of the subnet bits for NAC purposes, as some of us have been doing for IPv4 QoS and Security, well for IPv6, the associated dis-contiguous IPv6 wildcard masks are not an option. (Sigh!) I find myself wondering if there's a performance-related reason for that, or if someone was being a purist... I wouldn't think any IPv6 standard specifies wildcard bits.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.