Some people never learn and vigorously chase every new hype, be it OpenFlow or IPv6 – the evangelists of both technologies promised way more than the technologies were ever capable of delivering.

Not surprisingly, most of the overhyped technologies fail. It took IPv6 decades to get real-life adoption, and (according to Gartner) OpenFlow/SDN died before ever reaching mainstream deployments.

OpenFlow Is Like IPv6

Frequent eruptions of OpenFlow-related hype (example: Being Open about Virtualization and Cloud Interoperability published after Brocade Technology Day Summit) 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 Open Networking Foundation: “[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.

More to Explore

Want to hear the real-life SDN, OpenFlow or IPv6 story? Check out the ipSpace.net webinars available with standard subscription.

Revision History

2022-07-06
Replaced a link to a Brocade blog post with an archived copy

Latest blog posts in The OpenFlow/SDN Hype series

1 comments:

  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.
Add comment
Sidebar