Building network automation solutions

9 module online course

Start now!

The Four Paths to SDN

After the initial onslaught of SDN washing, four distinct approaches to SDN have started to emerge, from centralized control plane architectures to smart reuse of existing protocols.

As always, each approach has its benefits and drawbacks, and there’s no universally best solution. You just got four more (somewhat immature) tools in your toolbox. And now for the details.

2014-09-16 - added NX-API and management-plane protocols like NETCONF, XMPP and OpFlex.

Control-Data Plane Separation

The “original” (or shall I say orthodox) SDN definition comes from Open Networking Foundation and calls for a strict separation of control- and data planes, with a single control plane being responsible for multiple data planes.

That definition, while serving the goals of some ONF founding members, is at the moment mostly irrelevant for most enterprise or service provider organizations, who cannot afford to become a router manufacturer to build a few dozens of WAN edge routers… and based on the amount of resources NEC invested in ProgrammableFlow over the last years, it’s not realistic to expect that we’ll be able to use OpenDaylight in production environments any time soon (assuming you’d want to use an architecture with a single central failure point in the first place).

FYI, I’m not blaming OpenFlow. OpenFlow is just a low level tool that can be extremely handy when you’re trying to implement unusual ideas.

On a more positive note, reasonably-sized organizations could use OpenFlow to augment the forwarding functionality of existing network devices (in which case the only hardware one could use are a few HP switches, as no other major vendor supports send-to-normal OpenFlow action).

I am positive there will be people building OpenFlow controllers controlling forwarding fabrics, but they might eventually realize what a monumental task they undertook when they’ll have to reinvent all the wheels networking industry invented in the last 30 years including:

  • Topology discovery;
  • Fast failure detection (including detection of bad links, not just lost links);
  • Fast reroute around failures;
  • Path-based forwarding and prefix-independent convergence;
  • Scalable linecard protocols (LACP, LLDP, STP, BFD …).

Overlay virtual networks

The proponents of overlay virtual networking solutions use the same architectural approach that worked well with Telnet (replacing X.25 PAD), VoIP (replacing telephone exchanges) or iSCSI, not to mention the global Internet – reduce the complexity of the problem by decoupling transport fabric from edge functionality (a more cynical mind might be tempted to quote RFC 1925 section 2.6a).

The decoupling approach works well assuming there are no leaky abstractions (in other words, the overlay can ignore the transport network – which wasn’t exactly the case in Frame Relay or ATM networks). Overlay virtual networks work well over fabrics with equidistant endpoints, and fail as miserably as any other technology when being misused for long-distance VLAN extensions.

Vendor-specific APIs

After the initial magical dust of SDN-washing settled down, only a few vendors remained standing (I’m skipping those that allow you to send configuration commands in XML envelope and call that programmability):

  • Arista has eAPI (access to EOS command line through JSON-formatted REST calls) as well as the capability to install any Linux component on their switches, and use programmatic access to EOS data structures (sysdb);
  • Cisco’s OnePK gives you extensive access to inner working of Cisco IOS and IOS XE. NX-API does the same for Nexus 9K (it's so refreshing to get consistently incompatible APIs from the same vendor) and is supposed to become available on other Nexus platforms.
  • Juniper has some SDK that’s safely tucked behind a partner-only regwall. Just the right thing to do in 2014.
  • F5 had iRules and iControl for years (and there’s a Perl library to use it, which is totally awesome).

Have I missed anyone? Please write a comment (and no, I don’t want to hear about NETCONF support).

Not surprisingly, vendors love you to use their API. After all, that’s the ultimate lock-in they can get.

Reuse of existing protocol

While the vendors and the marketers were fighting the positioning battles, experienced engineers did what they do best – they found a solution to a problem with the tools at hand. Many scalable real-life SDN implementations (as opposed to works great in PowerPoint ones) use BGP to modify forwarding information in the network (or even filter traffic with BGP FlowSpec), and implement programmatic access to BGP with something like ExaBGP.

Also, don’t forget that we’ve been using remote-triggered black holes for years (the RFC describing it is five years old, but the technology itself is way older) – we just didn’t know we were doing SDN back in those days.

Finally, controllers focused on device- or service provisioning or orchestration commonly use existing management plane protocols like NETCONF or emerging protocols like XMPP or OpFlex.

XMPP is a pretty old protocol, its use in network management is the “emerging” part I had in mind in the previous paragraph.

Which one should I use?

You know the answer: it depends (and I'll got into more details in my SDN Deployment Considerations webinar).

If you’re planning to implement novel ideas in the data center, overlay virtual networks might be the way to go (more so as you can change the edge functionality without touching the physical networking infrastructure).

Do you need flexible dynamic ACLs or PBR? Use OpenFlow (or even better, DirectFlow if you have Arista switches).

Looking for a large-scale solution that controls the traffic in LAN or WAN fabric? BGP might be exactly what you need.

Finally, you can do things you cannot do with anything else with some vendor APIs (but do remember the price you’re paying).

Need more information?

Start with SDN resources @, download my new SDN book, or contact me to organize an on-site SDN workshop.


  1. NX-API from Nexus 9000 should be available on 7K now and soon 5/6K
  2. Very well written. I have followed your blog for years but not written any comment before now. Must thank you for all your excellent posts. Your blog is a great source of invaluable information. Inspiring and knowledgeable. Greetings from Sweden.
  3. Hey Ivan!
    Yes, you're missing Cisco's ACI/APIC which uses a new protocol called OpFlex: is it because it goes way beyond what current SDN can achieve right now? ;)

    Even Martin Casado talks now about policy-based SDN: see packet pushers show 203.
    1. OpFlex comes more under the "existing protocols", it's not a network element API. Assuming it's policy propagation protocol, it looks to be an alternative to NETCONF.
  4. Ivan, great article as usual. A couple of comments:

    I agree that using OpenFlow to augment forwarding functionality is a good use case: marking / steering large flows, blocking DDoS flood attacks etc. In addition to HP, there are a few other vendors that I am aware of that support OpenFlow NORMAL (integrated hybrid mode): Brocade, Alcatel Lucent Enterprise, and Mellanox.

    You didn't mention Cumulus. SDN protocols become much less important when you have an open Linux switch platform. You can compile and install your own management daemon and implement whatever protocol best suits the task (and blend local and remote control). For example, it is possible to build a simple REST API to manipulate ACLs using standard Linux iptables commands on Cumlus Linux in around 200 lines of Python.
  5. Really? Placing important documents behind regwall is so 2014? Have you tried accessing videos and documents at:

    I am sure we all have our own justifications for regwalls/paywalls.

    Disclaimer: I don't work for Juniper.
    1. Dear Anonymous,

      Just because you're upset that you cannot download the video that you want to watch without paying for it doesn't make it OK to write nonsense.

      Webinars are my core business and pay my bills so I can generate tons of free content that you obviously read (btw, how much free content did you generate lately?). Likewise, Junos is Juniper's core business and I never expected to get it for free.

      OTOH, putting documentation behind a regwall, particularly when similar documentation is freely available from your competitors, is self-defeating, or it might make people think that you have something to hide.

      Finally, I'm willing to have any (at least somewhat technical) argument you wish as long as you have the guts to put your name to your comment. Without that, the debate stops here.
Add comment