Summary Bullets:
- OpenFlow networking will require significant changes to your network operations and management. Without a killer app, why change?
- Ethernet is good enough for most companies and enhancements can improve its efficacy. OpenFlow competes with a ‘good enough’ technology that is less painful than switching.
OpenFlow can be an effective alternative to Ethernet when it is backed by a strong software or application-defined network (SDN and ADN, respectively). The resulting strategy opens up a world of opportunities to do networking better than we have seen in the last 20 years, but ultimately, OpenFlow desperately needs a killer app because plain old Ethernet is good enough.
OpenFlow does not replace or modify Ethernet like Transparent Interconnection of Lots of Links (TRILL) or Shortest Path Bridging (SPB). It is just a command and control protocol. Rather than having each switch learn the local topology and make its own forwarding decisions, the OpenFlow controller makes the decisions and tells the switch what to do. Therein lays the bet – that OpenFlow can replace Ethernet’s established and well-understood command and control system.
Replacing Ethernet with OpenFlow means all of the operational and technical dependencies that rely on Ethernet behaving a certain way have to change as well. All of the operations skill and knowledge that your staff, VARs, and vendors have developed over the years becomes irrelevant, as they have to learn the idiosyncrasies of controllers, switches, and APIs. The troubleshooting and monitoring tools that you have relied on are less useful when traffic can be driven automatically down diverse paths, which ultimately complicates troubleshooting. Unless you are going to rip and replace Ethernet with OpenFlow or put in a greenfield network, any transition will have problems such as requiring your OpenFlow network to implement Spanning Tree at the edge, because while OpenFlow can easily handle multiple Ethernet paths, your plain old Ethernet network cannot.
Do not underestimate the uplift required to move to OpenFlow. It is pretty massive, and frankly, it could be too high a hurdle to get over for most organizations. Vendors are wrestling with how to get skeptics to take an interest in OpenFlow, which is still a new technology. At the same time, enterprise IT is looking for the killer application that will make the move to OpenFlow worthwhile. Incremental improvements on what already exists, like being able to mirror network traffic to a packet analyzer or IDS via software, seem useful until you realize that you will need extra capacity in the network for the mirrored traffic anyway. Modern switch platforms can already perform remote tapping, and smart taps can do the same while sending the traffic out of band from your data network.
In fact, I have not seen a capability within OpenFlow or leveraging OpenFlow that is head and shoulders above Ethernet. Even multi-pathing sans Spanning Tree can be accomplished with TRILL or SPB, both of which are finding support in switch lines and neither of which requires a big change in operations and management. Between enhancements to Ethernet and product developments in Layer 4-7 services, enterprises can accomplish most of what they need without resorting to OpenFlow and a controller-based Ethernet network. That is the competition OpenFlow faces. Bring the killer app and OpenFlow has a chance at success.
IT Connection 