… updated on Tuesday, February 28, 2023 17:46 UTC
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.
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. Also, almost nobody is using OpenFlow and Open Daylight seemed to be pretty much dead in 2017 (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 could be extremely handy when you’re trying to implement unusual ideas… if only it were implemented on recent gear.
I am positive there will always be people building OpenFlow controllers controlling forwarding fabrics (see also: Faucet), 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.
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 has NX-API which is slightly better than sending configuration commands in XML envelopes – it can accept structured XML data.
- Juniper has some SDK that’s safely tucked behind a partner-only regwall. Just the right thing to do.
- 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 was published in 2009, 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.
Which one should I use?
You know the answer: it depends (you’ll find the details in the 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 DirectFlow if you have Arista switches, or BGP FlowSpec.
- 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?
You’ll find tons of real-life details vendors usually try to handwave over in the ipSpace.net SDN resources.
- OpenFlow and Open Daylight are mostly dead
- Cisco OnePK is definitely gone for good
- XMPP never really took off (apart from its use within Contrail)
- OpFlex is still there, but I was told it’s a royal pain to use, so I removed it from the blog post.
- BGP FlowSpec is recommended as the tool to implement ACL/PBR instead of OpenFlow
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.
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.
I am sure we all have our own justifications for regwalls/paywalls.
Disclaimer: I don't work for Juniper.
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.