One of the comments I usually get about OpenFlow is “sounds great and I’m positive Yahoo! and Google will eventually use it, but I see no enterprise use case.” (see also this blog post). Obviously nobody would go for a full-blown native OpenFlow deployment and we’ll probably see hybrid (ships-in-the-night) approach more often in research labs than in enterprise networks, but there’s always the integrated mode that allows you to add OpenFlow-based functionality on top of existing networking infrastructure.

Leaving aside the pretentious claims how OpenFlow will solve hard problems like global load balancing, there are four functions you can easily implement with OpenFlow (Tony Bourke wrote about them in more details):

• packet filters – flow classifier followed by a drop or normal action;
• policy based routing – flow classifier followed by outgoing interface and/or VLAN tag push;
• static routes – flow classifiers using only destination IP prefix and
• NAT – some OpenFlow switches might support source/destination IP address/port rewrites.

Combine that with the ephemeral nature of OpenFlow (whatever controller downloads into the networking device does not affect running/startup configuration and disappears when it’s no longer needed), and the ability to use the same protocol with multiple product families, either from one or multiple vendors, and you have a pretty interesting combo.

Actually, I don’t care if the mechanism to change networking devices’ forwarding tables is OpenFlow or something completely different, as long as it’s programmable, multi-vendor and integrated with the existing networking technologies. As I wrote a number of times, OpenFlow is just a TCAM/FIB/packet classifier download tool.

Remember one of OpenFlow’s primary use cases: “add functionality where vendor is lacking it” (see Igor Gashinsky’s presentation from OpenFlow Symposium for a good coverage of that topic).

Now stop for a minute and remember how many times you badly needed some functionality along the lines of the four functions I mentioned above (packet filters, PBR, static routes, NAT) that you couldn’t implement at all, or that required a hodgepodge of expect scripts (or XML/Netconf requests if you’re Junos automation fan) that you have to modify every time you deploy a different device type or a different software release.

Here are a few ideas I got in the first 30 seconds (if you get other ideas, please do write a comment):

• User authentication for devices that don’t support 802.1X;
• Per-user access control (I guess NAC is the popular buzzword) that works identically on dial-up, VPN, wireless and wired access devices;
• Push user into a specific VLAN based on whatever he’s doing (or based on customized user authentication);
• Give users controlled access to a single application in another VLAN (combine that with NAT to solve return path problems);
• Layer-2 service insertion, be it firewall, IDS/IPS, WAAS or some yet-unknown device;

Looking at my short list, it seems @beaker was right: security just might be the killer app for OpenFlow/SDN – OpenFlow could be used either to implement some security features (packet filters and traffic steering), to help integrate traditional security functions with the rest of the network, or to implement dynamic security services insertion at any point in the network – something we badly need but almost never get.