SDN: Concrete or Concept?

#SDN Is SDN a concept, or a concrete architectural construct? Does it really matter?

A question – specific to F5 technology – was raised during the panel session I moderated at Gartner DC 2012 that for me, at least, raised an interesting question. Well, actually it wasn't just that question, but rather the question was the icing on the cake after hearing commentary from enterprise IT attendees on the subject of SDN.

Yes, there's already a spate of SDN-washing, similar to cloud-washing, that's going on in the market. While ONF certainly laid out a set of characteristics defining SDN, those characteristics are not a concrete list of requirements. It's not, after all, an RFC, with an easy to evaluate list of "MUST NOT, MUST, SHOULD NOT, and SHOULD" requirements. As Captain Barbosa said, "…the code is more what you'd call "guidelines" than actual rule." 

The questions and commentary raised by IT attendees at the conference can be summed up in two questions:

1. What is SDN?

2. What problem is it trying to solve?

This is really the heart of the debate for IT. Adoption is not going to occur (one person out of the 50 attending the session had one guy, in a lab, playing with OpenFlow, for example) until at least the second of these questions can be definitively answered by those selling SDN solutions.

The answer to that question seems to center around a concept – agility. Agility, however, is also one of those broad terms that can mean anything from adaptability to flexibility to extensibility. Any of these concepts – and they are concepts – can be implemented in a variety of ways, some of which may fit the criteria set by ONF for SDN and some that may not. That's what leads to "washing" solutions; criteria using language and terminology that can easily be interpreted in a number of ways.

Let's refresh our memories, shall we?

“In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications. As a result, enterprises and carriers gain unprecedented programmability, automation, and network control, enabling them to build highly scalable, flexible networks that readily adapt to changing business needs.” [emphasis added]

-- Software-Defined Networking: The New Norm for Networks, ONF

Now, if we look at the benefits we can attempt to infer what the problems SDN is trying to solve:

BENEFIT	PROBLEM
Programmability	Network components today, particularly hardware-based components, run specific feature sets that can only be modified by the vendor, which happens on a 12-18 month schedule, security and hot-fixes not withstanding. New features and functions can only be added by the vendor based on their prioritization, not the customer.
Automation	Manual configuration of network components is time consuming, costly, and introduces a higher risk of human error that can result in outages, poor performance, or security risks.
Network control	The network today doesn't adapt rapidly to changing conditions or events. While some protocols simulate such adaptability, these protocols can't autonomously route around outages or failures or modify existing policies easily.

These are certainly problems for IT organizations of a variety of sizes and composition. The question then is, how does SDN uniquely solve those problems?

The answer is that as a concrete solution (i.e. components, software, and architectures)  it does not uniquely solve the problem. As a concept, however, it does.

Someone's no doubt quite upset at the moment at that statement. Let's explain it before someone's head explodes.

CONCEPT versus CONCRETE

The concept of separating data and control plane enables programmability. Without that separation, we have what we have today – static, inflexible networking components. But the concept of separating data and control planes isn't unique to solutions labeled specifically SDN. ADN is a good example of this (you saw that coming, didn't you?) 

A network component can – and this may surprise some people – internally decouple control and data planes. Yeah, I know, right? And doing so enables a platform that looks a whole lot like SDN diagrams, doesn't it – with plug-ins and programmability. This occurs in full-proxy architectures when there exist dual stacks – one on the client side, one on the server side. Where traffic transitions from one stack to the other exists an opportunity to inspect, to manipulate, to modify, the traffic. Because the architecture requires acting as an endpoint to clients (and conversely as the point of origin for the server side), protocols can even be implemented in this "no man's land" between client and server. That enables protocol transitioning, such as enabling SPDY on the outside while still speaking HTTP on the inside or IPv4 to servers while supporting IPv6 on the client (and vice-versa).

Where the separation occurs is not necessarily as important as the fact that it exists – unless you're focused on concrete, SDN-labeled solutions as being the only solutions that can provide the flexibility that programmability offers.

Automation occurs by exposing the management plane through an API (or implementing a specific API, such as OpenFlow) such that operational tasks and configuration can be achieved through tools instead of time.

Between automation and programmability, you realize network control.

Now, this is not SDN, at least not in terms of protocol support and concrete architecture. But it is software-defined, and it is networking, so does it count?

I guess it depends. ADN has always approached layers 4-7 with an eye toward extensibility, programmability and control that enables agility in the network. We didn't call it SDN and I don't see the industry deciding to "SDN-wash" existing ADN solutions as SDN just because a new term came along and became the TLA du jour.

What I do see is that ADN and specifically full-proxy based ADC (application delivery controllers) already offer the same benefits using the same concepts as SDN. Consider again the core characteristics of SDN:

1. Control and data planes are decoupled

2. Intelligence and state are logically centralized

3. Underlying network infrastructure abstracted from applications

All of these characteristics are present in an ADN. The ability to leverage network-side scripting on the control plane side of the equation enables extensibility, rapid innovation, and ability to adapt to support new protocols, new applications, new business requirements – all without involving the vendor. Which is exactly one of the benefits cited for SDN solutions and specifically OpenFlow-enabled architectures. 

So the question really is, does it matter if a solution to the problem of "agility in the network" is a concrete or conceptual SDN solution if it ultimately solves the same set of problems?

---