Following on from my first blog about OpenFlow, “Is OpenFlow Losing Its Openness?” I have done a lot of reading and have come to the below thoughts.
First, I still think OpenFlow is cool technology and may grow into a truly useful product/feature, but …
The issues as I see them.
The issues I find myself looking at with OpenFlow are as follows:
- It is run by companies who are looking at the very top end of town/the world.
- You cannot use it everywhere. There are hard limits to how many flows you can handle, and they are smallish.
- The forwarding decision of the controller is inherently much, much slower than on-switch forwarding decisions.
- Configuration of the network via OpenFlow lessens the spotlight on Netconf. (This I feel we need more than OpenFlow in the short term.)
- Openness of the controller has not even been thought of – interoperability of controllers, IF it arrives, will be chucked on afterwards and not designed in.
Some Q&A (my thoughts to your eyes).
Then why have so many networking vendors jumped on board supporting OpenFlow when it commoditizes their equipment?
We have Brocade, Cisco, Extreme, IBM, Juniper, HP and NEC, to name a few, all saying, “We support OpenFlow” or will soon.
Once again, we look at the companies running the ONF: global cooperates and large service providers. So when one of these large entities says, “Our company X is looking for 10,000 10 Gb Ethernet ports for ‘whatever’ that is compliant with OpenFlow version x.x”, they better have a product that fits or else miss out on a large opportunity.
So switches and routers will get cheaper right? They will be commodity products?
Nice try, but no, they still need all the intelligence – otherwise OpenFlow would not have anything to program.
My answer to a question from Greg.
Greg Ferro in his blog post Is OpenFlow Open ? I Ask – Compared to What ? asks the question, “What is the concept of open?”
Quote: ”So when Michael Schipp asks Is OpenFlow Losing Its Openness? I would have to question the concept of open. SNMP is open, but NMS are closed and data is sequestered into closed data silos.”
My answer here is firstly, HP OpenView is a NMS and of course much more. Is it open? To a point. Not by a standards body for sure, but how many different vendors offer plug-ins to OpenView? (However, would I use OpenView? Umm, no thanks.)
OpenFlow is less open than OpenView, insofar as at least HP has available API’s to access and integrate to OpenView.
Secondly, for “sequestered into closed data silos”, I would argue that most NMS’s use SQL as the backend and that most certainly is able to be retrieved. However, I have not ever tried to see if a database schema is available with any NMS offering.
However, Greg does indeed raise a good point here – how open is open and to whom? This is hard to say other than the ONF does not meet my definition of “open”. The protocol used to speak with the networking equipment must be open (public) otherwise it would not work, but I would add that the protocol to speak with other controllers would also be open (and again public). So like many other protocols, advertise what features you support to each other to come to a common denominator for interoperability. (This still leaves room for each vendor’s special sauce.)
So is Openflow losing its openness?
By the way I define it, it just was not as open as I had first thought or hoped for.
What about vendor lock-in?
At this point in time, if we need (because we deem it necessary to implement this style of control) to choose a vendor to lock-into, would you choose a new SDN/OpenFlow vendor or an established networking vendor?
OpenFlow is, at the end of the day, a way to program and/or configure the network. Are there other ways of doing this right now? Yes, we have Netconf for configuring switches/routers (note – not everybody supports this yet or fully). Some vendors have exposed their own API’s to allow both policy and flow based forwarding today, and we have had SNMP for configuring/monitoring for ages.
My view is at this stage, you will most likely have a better chance with a networking vendor to:
- Fix a bug (Yes I know, there should not be any. They test, right?)
- Request a feature
- Request help
What about closed loop, you ask?
Yes, even that is available today, some vendors support pushing sFlow to a IPS device and having that IPS unit requesting the switch to disable the port, rate limit the port, etc.
Of course, I know this works for only a single vendor, and this is why both Netconf and OpenFlow support will only continue to grow.
Will OpenFlow fix all the shortcomings in networking?
No, I do not believe so, as it will not scale to meet every flow in every switch as the same speed an individual switch can. But it has the potential to fix some of the issues we face today.
Who will use it and when?
- Educational bodies will continue to use it and some cool research will come of that over the next few years.
- Global companies and SP’s will be the first to pay for it and drive the commercial features and the short term goals.
- Enterprise will be about 3 to 5 years away from a valid use case at a price point where it would work.
As always, all feedback is welcome.
Thanks for reading,