Do Network Engineers Dream of Software Defined Sheep?

I really want Software Defined Networking (SDN), or something like it, to be the go-to approach for networking, but are we too tied to our idea of what SDN is for us to get there?

The Definition

Almost ten years ago in 2009, Kate Green coined the term Software-Defined Networking in an article describing the newly-created OpenFlow specification that would be released later that year. The idea was revolutionary: Decouple the forwarding plane from the control plane and move the latter to a centralized controller. The controller would then manage the forwarding plane of the individual devices in the network from a global perspective. This would allow the entire network to be managed via a single interface to the controller. For some time following this, SDN became synonymous with OpenFlow, but the philosophy has exceeded the implementation.

A Cloud Technology?

In an admittedly questionable Wikipedia page, SDN is defined as "an approach to cloud computing that facilitates network management and enables programmatically efficient network configuration in order to improve network performance and monitoring." This is an interesting perspective, considering that OpenFlow appears to have been developed with large service provider networks in mind. So where does it go from being a service provider technology to a cloud technology? Large service providers and cloud (particularly public cloud) providers have one thing in common: scale. In previous articles, I've discussed network automation in the cloud as a requirement rather than a desired state. Arguably, large networks of any sort share this property. When working at scale, there really isn't any other way to do things effectively. This, of course, doesn't mean that the approach isn't desirable outside of large-scale environments. Still, need drives progress and the market focuses on the need.

Silo Busting

Since I began my career in networking (too) many years ago, technologies were placed in seemingly arbitrary categories and vendors tended to develop equipment with feature sets that followed these silos. Invariably, there's bleed from one category to another when new requirements surface. So why are we maintaining these categories in the first place? Networking is networking. If the solution for an enterprise business requirement is traditionally a data centre networking or service provider networking technology, use it. For many years the IS-IS routing protocol was considered a service provider technology. Now, with its ability to handle IPv4 and IPv6 under a single routing architecture, it's getting a resurgence in the enterprise. MPLS VPNs have mostly been in the service provider category, but are becoming seen in enterprise networks for organizations that need to support franchise network connectivity over the parent organization's network. Shortest Path Bridging (SPB) was developed as a data centre networking technology, but is arguably an ideal replacement for Spanning Tree Protocol (STP) in general. We need to think beyond the silos and look at networking as networking if we're going to escape the current state of micromanaging equipment. This means bringing SDN out of the cloud and service provider categories.

Delegation of Control

One of the key concerns about SDN that I've heard over the years is the problem of relying on a controller (or cluster of controllers) to make forwarding decisions. This approach is really good for standard routing and network functions that can be addressed globally. It falls down a bit when it comes to things like security policies at the edge, policy-based routing, and other exception-based items that are device-centric rather than network-centric. Can we have an SDN architecture where the control plane is still distributed, but managed at the controller? Is it still SDN? The purists may argue, but in the same vein as the silos above, it doesn't really matter. We may need another term for it, but SDN can work for now, and here's why.

An Imperfect Dream

When I first considered writing this article, I was running under the working title of "When SDN Isn't" because I was frustrated with the number of solutions that purported to be SDN, but really weren't for various reasons. Some of them did not centralize the control plane under a controller. Others didn't provide open northbound APIs into their controller. Now I'm starting to think it's time to expand the practical definition a bit. At its core, SDN works by allowing software to define requirements to the controller via a northbound API. The controller then programs the component devices or virtual devices via a southbound API. Taking the actual term Software Defined Networking literally, these are the key requirements. If the component devices are programmed at the flow level by a controller that has the entire control plane centralized, and it meets the needs of the organization, that's awesome. If those devices have their own control planes and their decision making is defined at a higher level by the controller, that's just great too, again, so long as it meets the needs of the organization.

The Whisper in the Wires

SDN, or a relaxed definition of it, has the potential to be the holy grail of networking in general, but we're still stuck thinking in networking silos: cloud, data centre, service provider, enterprise, small/medium business, etc. What we want is a central and programmable interface to the entire network and to stop micromanaging devices. How that is accomplished below the controller level should be immaterial.

Originally published on SolarWinds' orangematter site.