The Does Centralized Control Plane Make Sense post triggered several comments along the lines of “do you think there’s no need for OpenFlow?”

TL;DR version: OpenFlow is just a low-level tool; don’t blame it for how it’s being promoted… but once you figure out it’s nothing more than TCAM (ACL+PBR) programming tool, you’ll quickly find a few interesting use cases. If only we’d have hardware we could use to implement them; most vendors gave up years ago.

OpenFlow is just a tool that allows you to install PBR-like forwarding entries into networking devices using a standard protocol that should work across multiple vendors. From this perspective, OpenFlow offers slightly more advanced functionality than BGP FlowSpec.

Where could you use PBR-like functionality? I’m positive you already have a dozen ideas with various levels of craziness; here are a few more:

• Network monitoring (flow entries have counters);
• Intelligent SPAN ports that collect only the traffic you’re interested in;
• Transparent service insertion;
• Scale-out stateful network services;
• Distributed DoS prevention;
• Policy enforcement (read: ACLs) at the network edge.

OpenFlow has another advantage over BGP FlowSpec – it has the packet-in and packet-out functionality that allows the controller to communicate with the devices outside of the OpenFlow network. You could use this functionality to implement new control-plane protocols or (for example) interesting layered authentication scheme that is not available in off-the-shelf switches.

Summary: OpenFlow is a low-level tool that can help you implement numerous interesting ideas, but I wouldn’t spend my time reinventing the switching fabric (or other things we already do well).

For more information, watch the ipSpace.net SDN webinars (some of them are free).