Published: 24 May 2011
If you haven’t spent the last few weeks on a forgotten island with no satellite phone coverage, you’ve probably noticed the spiking levels of hype surrounding the newest internetworking technology OpenFlow. The networking industry is obviously in dire need of the next big thing. The last time I saw something similar to this was in the early 2000s when MPLS was supposed to solve every internetworking problem ever envisioned. In those days the levels of hype were so high that someone wrote an April 1st RFC describing the use of MPLS for electricity transport.
Read Ivan's IOS Hints Blog
Stateless NAT is useless
Scaling IAAS network infrastructure
Like MPLS, OpenFlow won’t bring world peace, cure cancer or discover alien civilizations. It might, however, help change the internetworking environment in the same way Unix and Linux changed the operating system landscape by providing a standard way of configuring forwarding tables in a distributed switching architecture.
But that doesn't account for the explosion of OpenFlow announcements at Interop. After all, OpenFlow was an unknown academic toy only a few months ago. In fact, the speed with which vendors were able to throw together a proof-of-concept code indicates one of the drawbacks of OpenFlow: it’s a simple low-level API (some people are comparing it to BIOS). The hard part of the exercise will be writing the controller software that everyone is already raving about. But that won't be easy. Networking vendors have invested thousands of man-years into similar efforts. So those that expect revolutionary new controller applications appearing out of the blue sky probably also believe in tooth fairy and unicorn tears.
Read more Fast Packet bloggers
Fast Packet blogger Greg Ferro explains the rise of OpenFlow and the software-defined network.
News editor Shamus McGillicuddy questions whether enterprises really need the network testing equipment typically used by carriers.
Fast Packet blogger Michael J. Martin warns that a full IT infrastructure audit is necessary if you're going the virtualization route.
One of the most extreme analogies I’ve heard so far compared OpenFlow to a C compiler. Instead of using off-the-shelf applications, now we have the ability to develop our own. This might be true, but someone still has to develop these applications, test them and make sure they scale, which is one of the biggest hurdles OpenFlow has to cross. Meanwhile, vendors are already touting controller applications as the “magic” ingredient, but I wouldn't expect miracles. As technical guru and professor Scott Shenker explained: “[OpenFlow] doesn't let you do anything you couldn't do on a network before.”
Moreover, even if OpenFlow were comparable to a C compiler, we haven’t seen an explosion of database packages or spreadsheet programs just because we have a C compiler. A few vendors own the majority of the market in each application segment, and the OpenFlow controller landscape might look very similar in a few years. There will likely be a few makers of commoditized hardware based on common merchant silicon and a few software vendors (probably including Cisco, Juniper and VMware) providing the vast majority of the controller nodes. And just in case you still believe OpenFlow will bring down prices and shrink the fat margins of some internetworking companies, take a brief look at Oracle’s financial reports.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor atNIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out hisIOS Hints blog.