Every other week I stumble upon a high-level SDN article that repeats the misleading SDN is centralized control plane mantra (often copied verbatim from the Wikipedia article on SDN, sometimes forgetting to quote the source).

Yesterday, I had enough and decided to respond.

Would everyone please get the terminology right? Central controller (or centralized visibility or central policy engine) is not centralized control plane.

Control plane in network devices (or distributed systems) is a well-defined concept that implements not only routing protocols (as is commonly understood), but also real-time protocols like spanning tree BPDU, LACP, link failure detection mechanisms like BFD and UDLD and even host-to-network protocols like ARP. More details in:

• Management, Control and Data Planes in Network Devices and Systems
• What Exactly Is the Control Plane?
• Control Plane in OpenFlow Networks
• Implementing Control-Plane Protocols with OpenFlow

The former makes perfect sense, particularly when combined with business-as-usual distributed forwarding to augment its behavior, the latter makes absolutely no sense in real world, no matter what its proponents claim.

Centralized control, be it configuration or policy management, traffic engineering or exception routing (aka PBR) significantly simplifies hard-to-solve problems that benefit from centralized visibility. Controller-based networks (or orchestration systems if you prefer that terminology) have a bright future. They also have a long history – there are numerous home grown or commercial products that implemented some variant of centralized control for decades (example: Cariden MATE or service provisioning systems).

Centralized control plane (implementing a reasonably complete set of control-plane protocols, including host-to-network protocols and fast failure discovery) cannot scale, as every implementer of a commercial OpenFlow-based product had to admit sooner or later. Let me just list a few examples:

• NEC pushed the envelope the furthest with their ProgrammableFlow controller, but only because they decided not to implement most control-plane protocols;
• Nicira was using OpenFlow in their Network Virtualization Platform (NVP), but deviated from it the moment they had to implement layer-3 forwarding and ARP. Subsequent Linux networking software from the Nicira team (Open Virtual Networking) used a combination of centralized policy and forwarding information distribution with local intelligence (on-host agent);
• Big Switch Networks got a scalable product only when they deviated from the pure concepts of OpenFlow and centralized control plane, and implemented control-plane protocols locally;
• HP decided to use OpenFlow to augment traditional distributed forwarding, not replace it, because (in their own words) that’s the only architecture that makes sense;
• Even Google (in its OpenFlow-based WAN network) used centralized control plane within a single WAN edge node (a tightly-coupled leaf-and-spine fabric), while relying on traditional routing protocols between WAN edge nodes.

At this point it’s worth noting that all traditional centralized networks (Frame Relay, SDH/SONET, even SNA) always contained some local intelligence, because that’s the only approach that scales.

Further Reading

• Is Controller-Based Networking More Reliable than Traditional Networking?
• Control and Data Plane Separation – Three Years Later
• What Exactly Is SDN – and Does It Make Sense?
• The Four Paths to SDN
• OpenFlow Fabric Controllers Are Light-Years Away From Wireless Ones

Product-specific blog posts:

• Big Cloud Fabric: Scaling an OpenFlow Fabric
• Layer-2 and Layer-3 Switching in VMware NSX
• There’s a Difference Between Scaling and not Being Stupid
• OpenFlow in HP Campus Solutions
• OpenFlow @ Google: Brilliant but not Revolutionary

You might also want to explore my other SDN- and OpenFlow-related blog posts.

For even more details, explore my SDN webinars and other SDN resources:

• Start with the free Introduction to SDN pack;
• Explore SDN architectures and their scalability challenges;
• Find out all the details of the OpenFlow protocol;
• Get 20+ hours of SDN and network automation content with Advanced SDN training.