Let get started with some background:
The OpenFlow Switching specification was created in 2008 to evangelize and support OpenFlow. Although hosted at Stanford University, our goal is for OpenFlow to be owned by the community – for the betterment of research and innovation in networking.
The Stanford OpenFlow Team
First let’s look at what OpenFlow was meant to do in 2008. From the introduction found at http://yuba.stanford.edu/~jnaous/papers/ancs-openflow-08.pdf
Today it has become extremely difficult to innovate in the computer networks that we use everyday in our schools, businesses, and homes. Current implementations of main-stream network devices, such as Ethernet switches and IP routers, are typically closed platforms that cannot be easily modified or extended. The processing and routing of packets is restricted to the functionality supported by the vendor. And even if it were possible to reprogram net-work devices, network administrators would be loathe to allow researchers and developers to disrupt their production network. We believe that because network-users, network-owners and network-operators cannot easily add new functionality into their network, the rate of innovation—and improvement—is much lower than it Rather than leave network innovation to a relatively small number of equipment vendors, our goal in the OpenFlow project  is to enable a larger population of researchers and developers to evolve our networks, and so accelerate the deployment of improvements, and create a marketplace for ideas. Today, most new ideas proposed by the research community—however good—never make it past being described in a paper or conference. We hope that OpenFlow will go so someway to reduce the number of lost opportunities.
Good, right? This might be where Greg Ferro gets his woody from. There is much to like about this – even crave.
Now, let’s fast forward to 2012.
OpenFlow is not only alive and well, but coming at us full steam. But in what form?
From “Twilight in the Valley of the Nerds” blog post found at http://nerdtwilight.wordpress.com/2012/02/03/thinking-about-sdn-controllers/#comment-25480 which refers to a comment from Nicira’s Casado that was written last spring, “you most likely will not have interoperability at the controller level (unless a standardized software platform was introduced).”
This statement floored me! If an Ethernet vendor brings out something new, we expect that it is completely standards based. If it’s proprietary (like Juniper’s QFabric), we slam them. Why do we slam them? Because we do not want vendor lock in!
Okay, what is the statement from Casado really saying? Let’s see, first if you take vendor X’s OpenFlow controller then you better have ALL vendor X’s controllers everywhere – full stop, end of sorry – thanks for coming – see ya next upgrade.
So, I guess my questions are…is there an IETF, IEEE or any other recognized standards body for OpenFlow other then the ONF? What about controller interoperability – is this a part of any draft OpenFlow ONF version? Where is the “open” without that?
As far as I can see, the answers are “No,” “No,” and “Not much!”
Now that Stanford has given OpenFlow over to the world, and the Open Networking Foundation (ONF) has taken up Openflow as their own, let’s look at who is on the board of the ONF.
- Deutsche Telekom
Can anybody pick a name from that list that cannot do networking well, yet has more API’s then you can poke a huge stick at? Can anybody see that an OpenFlow controller might be coming to you *free* in an new Operating System?
I do hope I am missing something here, as from what I can see so far, all we are doing is moving the vendor lock in from the switch/router players to the OpenFlow players.
Please somebody tell me, “Sorry mate, you missed XYZ – this was addressed in ABC.”
Thanks for reading. All comments/corrections/enlightenment welcome!