Another great question I got from David Le Goff:

So far, SDN is relying or stressing mainly the L2-L3 network programmability (switches and routers). Why are most of the people not mentioning L4-L7 network services such as firewalls or ADCs. Why would those elements not have to be SDNed with an OpenFlow support for instance?

To understand the focus on L2/L3 switching, let’s go back a year and a half to the laws-of-physics-changing big bang event.

OpenFlow started as a research project used by academics working on clean-slate network architectures, and it was not the first or the only approach to distributed control/data plane architecture (for more details, watch Ed Crabbe’s presentation from the OpenFlow Symposium). However, suddenly someone felt the great urge to get OpenFlow monetized, had to invent a fancy name, and thus SDN was born.

The main proponents of OpenFlow/SDN (in the Open Networking Foundation sense) are still the Googles of the world and what they want is the ability to run their own control-plane on top of commodity switching hardware. They don't care that much about L4-7 appliances, or people who’d like to program those appliances from orchestration software. They have already solved the L4-7 appliance problem with existing open-source tools running on commodity x86 hardware.

Does OpenFlow/SDN make sense in L4-7 world?

It makes perfect sense to offer programmable APIs in L4-7 appliances, and an ever-increasing number of vendors is doing that, from major vendors like F5’s Open API to startups like LineRate Systems. However, appliance configuration and programming is a totally different problem that cannot be solved with OpenFlow. OpenFlow is not a generic programming language but a simple protocol that allows you to download forwarding information from controller to data plane residing in a networking element.

Is OpenFlow still useful in L4-7 world?

If you really want to use OpenFlow to implement a firewall or a load balancer (not that it’s always a good idea), you can use the same architecture Cisco used to implement fast path in its Virtual Security Gateway (VSG) firewalls: send all traffic to the central controller, until the controller decides it has enough information to either block or permit the flow, at which time the flow information (5-tuple) is installed in the forwarding elements. Does this sound like Multi-Layer Switching, the technology every Catalyst 5000 user loved to death? Sure it does. Does it make sense? Well, it failed miserably the first time, but maybe we’ll get luckier with the next attempt.