No. The idea behind OpenFlow is having simple routers which only implement basic switching capabilities in hardware. The complex routing rules can then be set in software which allows for much easier and more capable traffic routing.
It also allows more innovation in this part of the infrastructure which has traditionally been very resistant to it because of the incumbent players. You can, for example, experiment with new routing protocols without having to do a firmware or even hardware upgrade.
Traditionally the argument has been specialized hardware doing function X, will be faster (but not customizable, upgradable) compared to doing function X in software on commodity hardware (slow but upgradable).
And fpga were pointed out as somewhere in the middle ( some hw customization using sw)
What are your thoughts on the argument that by using commodity hw & implementing routing algos, etc in sw, will be more flexible but slower.
Is there a significant performance/speed cost when you implement core networking features in sw ?
Specialized hardware will be faster than software for a long time. OpenFlow ist smart enough to go around this problem. The routing still takes place in specialized hardware and is therefore just as fast as in a standard device.
The routing layer in hardware acts on a set of cached rules which are very simple. Simplified, you can imagine them to be of the form Matching Rule -> Routing Action. The matching rule selects by the packet fields such as source port or destination IP. The routing actions could be "forward to port" or "drop packet". All of this is just as fast as in every other commodity router.
What is special in OpenFlow is another possibility for the "routing action" field (or for unmatched packets): You can send certain packets up into the software level, to the OpenFlow controller. This can be a centralized server and the logic is implemented in software. The software decides about the routing of these kinds of packets and sends the answer back to the router. Here the rule is cached again and from now on the routing for this is as fast as for all the other packets.
This last bit is the only part which is slower compared to commodity routers. A really great solution in my opinion.
As I said in the last thread http://news.ycombinator.com/item?id=3847934 , words like "specialized" and "commodity" are being thrown around in unusual ways. With OpenFlow, your "commodity" hardware is line rate, so it's no slower than whatever it's replacing.
No it's not a routing protocol, but it makes the router so configurable that you're able to switch the protocols out easily. You could even invent your own for your internal network. I guess this is what Google has done because they have so much knowledge about their traffic and infrastructure.
It's not only about routing protocols though. It also allows you to do traffic shaping and all kinds of cool stuff as well. Just imagine a software router which is just as high speed as one which implements the logic in hardware.
My impression is that OpenFlow is most useful for internal networks. Instead of having smart switch, you have controllable switches and a smart controller. But I guess it would be useful for splitting up border routers into a switch and controller that does the routing and talks BGP.
Think of it as an automated method for providing configuration convergence across an infrastructure, instead of relying on manual input of routing tables.
Oops, my bad -- I didn't know OpenFlow 1.2 had been released because openflow.org hasn't been updated since early December. (I had it bookmarked and checked it occasionally just to see if IPv6 support ever got added.) The last I had heard/read, IPv6 support was just a proposed feature for a future spec...
Development and releases of the OpenFlow specification have been shifted to the Open Networking Foundation[1], so you can find the latest OpenFlow release (currently 1.2) over there. It has only come out recently though, so actual hardware & software support for the new version of the protocol is still quite young.
