OpenFlow State of the Union: Reflections on the OpenFlow Symposium

Listening to the OpenFlow Symposium panel speakers today (enough brain power in the room to blow the roof off of the hotel), I took away a few interesting points. At least, I took away my spin on a few interesting points.

1. What’s the status of OpenFlow as a usable protocol? Well, folks ARE using it. But it would be most fair to categorize OpenFlow as immature, emerging, and still trying to sort out what direction it’s heading in. The OpenFlow 1.0 spec is what production implementations are running on, not 1.1. The 1.1 spec seems to be a non-starter for vendors, due to issues which will be resolved in OpenFlow 1.2. The 1.0 spec was categorized by speakers today as simplistic, which means that while you can still do interesting things with it, the functionality is limited. OpenFlow 1.2, 1.3, and 1.4 are being worked on. OpenFlow 2.0 is in the “we’re waiting for customer input to know where we’re going with it” state.
2. What can I do with OpenFlow? Hmm. This was one of the fuzzier areas today. Based on the spec, a controller programs the flow table of an OpenFlow switch to forward traffic in a way that you specify based on certain criteria of the frame or packet. The general direction folks were heading was related to traffic steering, usually at the access layer. Organizations with specific, well-known-to-them, generally static, and predictable compute environments also leveraged OpenFlow to do specific things. There were more ideas thrown around as opposed to concrete “this is exactly what we’re doing.” I believe the OpenFlow magic will come when we see vendors writing clever applications that inform the controller in clever ways. I believe this will manifest itself most keenly in the areas of network virtualization, software defined networking (a term that somewhat means what you want it to mean at the moment), and automation. But I also believe that OpenFlow is only one piece of these rather large puzzles.
3. Is OpenFlow going to disrupt the networking industry? The answers to this question  from the panel ranged from “it already has,” to “not really.”  Some vendors felt that those ignoring OpenFlow would be made irrelevant in the marketplace before too long. Others thought it unlikely to change the market landscape. From my perspective, the answer to this question of market disruption is most closely tied to commoditized switches. Specifically, if de-coupling the control-plane from the switching hardware allows for OpenFlow-capable network switches to be produced dirt-cheap when compared to their integrated cousins, then that could be disruptive. Maybe. And the reason I say “maybe”, is that it depends a great deal on what you think you can do with your OpenFlow controller(s) and cheap switches, and how (and when) that might drive your purchasing decisions. That said, do you think you’re going to replace your entire data center with OpenFlow? Probably not, even if you could…which you can’t. (Next question.)
4. Assuming I wanted to, can I replace my entire data center with OpenFlow? Not today. Not tomorrow. And my guess is, probably not ever. Limited functionality in the OpenFlow spec in one reason (at least today – admittedly new specs are coming), but another more poignant reason is that there’s a scaling challenge related to the forwarding of microflows that I believe means devices like load-balancers are not going to be replaced anytime soon. What’s a microflow? Well, if a regular old data flow could be categorized as a forwarding decision made by destination IP address, then a microflow is when you start to make forwarding decisions on more granular frame or packet characteristics. In a straightforward routing application, there’s not a lot of flows to be considered. You can have a whole lot of conversations heading for a /24 netblock that all would be considered a single flow…because they’re all forwarded based on a single criteria defined by a single flow in a flow table. But when you get more granular, say forwarding non-contiguous IP blocks with sundry destination ports (typical in large load-balancer environments), then you’re dealing with microflows. That’s harder to scale. The scaling issue is within the netflow switch. When the switch sees a flow that does not match on any of the flows in its flow table, it punts that packet to the CPU. The switch CPU in turn forwards that packet to the OpenFlow controller. My understanding is that the switch CPU is where the bottleneck is. NEC suggested to me that an OpenFlow switch CPU could effectively punt about 1,000 unknown flows per second. The controller, probably running on a multi-core Intel CPU, is actually NOT the bottleneck, although certainly punting to the switch CPU, forwarding to the controller, and the controller making a decision about the flow and writing the flow entry into the switch flow table, all adds latency (in the tens of microseconds). I’m not going to get into other large-scale concerns that OpenFlow faces relating to controller to switch communication integrity and controller hierarchy (as in, there is no such thing today), but there are other concerns to be sure.
5. What is the OpenFlow killer app? I feel that the killer app is that you can now add features to your network that you couldn’t get your favorite networking vendor to add for you. If OpenFlow is a unicorn, you get to make it cry whatever tears you’re looking for. That’s it. That’s the killer app, at least in so far as I could see today. It’s not that there’s some specific, well-defined, universally recognized networking problem that OpenFlow solves. It’s more that OpenFlow enables network programmability via a predictable interface. Therefore, if there’s some unique problem you happen to have that traditional networking architectures can’t resolve for you due to technical, practical, or financial limitations, then OpenFlow might just provide a liberating answer.

More to come on this line of thought. NEC is presenting at Tech Field Day, and I’m keen to hear more about how their shipping OpenFlow solution might bear on the enterprise, the corner of networking that I call home.

What do you think? Did I get something wrong? No worries – I’m happy to correct anything I got wrong or context I’m missing. Just let me know in the comments.