Defining SDN Down

If a WAN product that uses software to control the flow of traffic is an SD-WAN, and a data center than uses software to build a virtual topology is an SD-DC, and a storage product that uses software to emulate traditional hardware storage products is SD storage, and a network where the control plane has been pulled into some sort of controller an SDN, aren’t my profile on LinkedIn, and my twitter username @rtggeek software defined people (SDP)? A related question — if there are already IoT vendors, and the IoT already has a market, can we declare the hype cycle dead and move on with our lives? Or is hype too useful to marketing folks to let it go that easily? One thing we do poorly in the networking world is define things. We’re rather sloppy about the language we use — and it shows.

Back on topic, but still to the point — maybe it’s time to rethink the way we use the phrase software defined. Does SD mean one thing emulating another? Does SD mean centralized control? Does SD mean software controlled? Does SD mean separating the control plane from the data plane? Does SD mean OpenFlow?

I’ll give you my definitions; you can disagree in the comments.

SDN specifically means placing an API between the database/table/information that is actually used (first hand) to forward traffic through a device so some controller software located off the device can manage the forwarding table remotely. I would carry this farther to state that the forwarding device, itself, should not be running a control plane that discovers reachability across multiple forwarding hops in the network, and doesn’t generally discover anything more than a single hop of topology. Hence, protocols like EIGRP, OSPF, BGP, and IS-IS are not something that would run on the device with the remotely managed forwarding table. Things like ARP, while arguably part of the control plane, are still run locally on the device — but anything that provides reachability through another device is decidedly not running on the device.

The location of the controller in this sort of situation is up for grabs. It could be simply a routing process running in a VM someplace else. It could control multiple devices. There could be one device managing a few racks, an entire data center fabric, or even an entire network. What’s important is where the API lies, and what type of information is discovered locally.

A programmable network, on the other hand, is one in which some or all of the control plane has been moved off the forwarding devices and into some sort of controller. The primary API, in this case, is to the table which feeds the actual forwarding table — the table from which the actual forwarding table is developed. This is what I would normally call the Routing Information Base (RIB). Some sort of multihop reachability discovery could/would still be running in such a device; IS-IS might still be used to discover the topology and reachable destinations, while the controller overlays the network with what I would consider policy, or rather anything that overrides the shortest path in order to modify traffic flow for any reason.

It seems, to me (if these are acceptable definitions) that the future specifically lies in a combination of SDNs and programmable networks. SDNs, in their pure sense, are useful within a limited scope; some number of devices placed under the control of a single controller. The controller then participates in a distributed control plane that carries reachability and topology information between individual devices and other controllers. On top of this lays a set of controllers that manage the policy in the network, directly injecting information into the network at the distributed control plane level rather than configuring policy through things like interface level access lists. If we’re going to get to a truly dynamic network, we need to get away from using things that show up in a local configuration for policy in the control plane.

Somehow we need to stop yabbering about SD-this and SD-that, and actually build a model we can all agree on, with a more defined set of terms, so we can have an actual conversation that doesn’t involve misdirection and marketing hype.

In the mean time, I think I’ll back and check on my SDP.

Don’t forget to sign up for the Rule 11 Reader.