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.
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).