Building network automation solutions

9 module online course

Start now!
While the original SDN idea (centralized control plane will solve all networking challenges) failed miserably, SDN became a must-use keyword, and vendors started calling network management systems or service provisioning systems SDN controllers.

SDN Controller Taxonomy

Even though Gartner declared SDN obsolete before plateau in their 2021 Networking Hype Cycle, most vendor marketers never got the memo. Anything that interacts with network devices in any way1 is called an SDN controller. Let’s try to throw some minimal amount of taxonomy into that mess based on how these controllers interact with network elements (physical or virtual).

Centralized control plane solutions are what Gartner considered to be SDN. Apart from a few well-architected niche solutions2, the laws of physics won. Centralized control plane was always a bad idea, and most people involved in the SDN orthodoxy eventually realized that after sobering up from a hype-induced trip3. Nothing much to see here.

Controllers interacting with the control plane. Most SD-WAN controllers are in this category. At the very minimum, they have to act as BGP route reflectors: collect reachability information from the SD-WAN appliances and distribute it to other appliances.

Network virtualization controllers4 are often in this category as well. Many of them use a control plane protocol (often EVPN) to interact with the outside world… although I wonder whether that’s a good idea. It’s interesting to see the gradual move away from the control plane interactions in VMware NSX Controller5 – as the product is built on ideas that came from one of the early proponents of centralized control plane, they must have hit some interesting scaling problems to move in that direction.

Orchestration systems. Why would you want to call a system that provisions a service by configuring the network elements in the background an SDN controller? Oh, it’s like bridge and switch – the marketing needed a flashy new name for an old idea, and SDN was all the rage when they made the decision.

Even in this segment, there are solutions that provide true abstraction of services. A prime example is probably Cisco ACI with its endpoint groups and contracts.

Then there are solutions provisioning group policies and network services across a range of network elements. For example, you could configure a VLAN segment implemented with VXLAN and EVPN (or LISP) on all edge switches in your fabric, or an SSID across a set of wireless access points. Cisco SD-Access, Pluribus Unified Cloud Fabric, and Ubiquity UniFi SDN Controller are probably in this category.

Finally, you might encounter someone rebranding a traditional device-focused network management system into an SDN controller, proving that the marketing shenanigans are indeed limitless.

Have I missed something?

Your comments (preferably including links to documentation) would be most welcome, including further examples of products in each category.

In case you want to send me a private message, you already have my email address if you have an subscription, or if you’re subscribed to my SDN/automation mailing list, and there’s the Contact Us form for everyone else.

  1. Even when it’s using an Ansible playbook with screen scraping over an SSH session ↩︎

  2. Including a surprisingly-stable and working SDN controller↩︎

  3. Some of them with an enormous headache, in particular when they worked for a vendor that bet the farm on OpenFlow. ↩︎

  4. Including most large-scale public cloud implementations. ↩︎

  5. Now part of NSX Manager ↩︎

Latest blog posts in The OpenFlow/SDN Hype series


  1. SR-MPLS with a PCE might be an example that fits into the "interacts with the control plane" category. I'm not that familiar with it so I'm not sure if you need to do config changes to tell a router to use a PCE path or if that's included in PCEP.

    1. PCE controllers are definitely in the "interaction with the control plane" category, regardless of whether they're used in traditional RSVP-TE, SR-MPLS, or SRv6 environments.

      I might be missing something, but it looks to me like PCE was designed to find paths for TE tunnels that have been configured through some other means. There's also an option of creating tunnels "out of thin air"; I'm assuming you need something like IGP autoroute to make them work.

Add comment