SDN: Capability or Context?

Why is it that the definition of SDN continues to get debated?

I think the definition of SDN remains a bit squishy. And while I am not entirely certain that it matters (people shouldn’t be buying SDN; they should be building networks), it is an interesting phenomenon, and understanding it better could help with the education process.

When most people talk about what SDN is, they tend to fall into two camps: principles and protocols. You will frequently hear SDN described as the separation of control and forwarding planes. You probably hear people talking about SDN needing to be “open” (a horribly imprecise term as I have argued before). These are the people who fall on the principles side. They point less to specific instantiations of technologies and more to the guidelines that define SDN.

The other camp will point to specific protocols and technologies. They rally around the OpenFlow banner for sure, but they might include other technologies like BGP-TE, PCE, ALTO, and I2RS. They see SDN as an architecture with specific building blocks, and the presence of those building blocks determines the SDN-ness of a solution.

I actually don’t think that either of these positions is correct.

I was debating last week whether GMPLS was SDN. It certainly focuses on the separation of control and forwarding plane. It is an open standard. It is absolutely implemented in software. It seems to hit most of the framework criteria for inclusion in the SDN camp. The conclusion of whether GMPLS is SDN or not is less interesting than the discussion that surrounded it.

Does software define software-defined? Claiming something is software-defined because it is implemented in software is probably among the lamest definitional requirements around. The reality is that the vast majority of traditional networking features are all implemented in software. In fact, the major vendors spend north of 80% of their R&D on software-related efforts. By this definition, everything is software-defined.

The real distinction people seem to be trying to make when they talk about software implementations is whether the functionality is resident on a networking device, or whether it sits somewhere on top of the network (as with a controller). But we should be clear about this. Whether some application runs on or off the box is a packaging detail, not some core attribute. Networking devices all have some forwarding ASIC and a general processor. Whether you write something to run natively within the sheet  metal or on some server somewhere is irrelevant. Put differently, if your vendor of choice decided to ship their boxes with the central processing card physically separated (it sits a half micron on top, with separate sheet metal, power, and cooling), would you suddenly brand the solution software-defined?

[Special callout to Mike Dvorkin (@dvorkinista) who frequently makes this argument on social channels.]

Is the separation of control and forwarding the meaningful determinant? Network device behavior is all state-driven. Whether that state is determined by persistent configuration or learned through some protocol is secondary. More simply, how important is it how state gets onto the device? More simply, if you set the state via an on-box CLI or via a controller, does that make the solution any more or less SDN?

When most people talk about control and forwarding, they are really having a discussion about management planes. Controller-based solutions certainly separate the management plane. But so do policy servers, OSS/BSS solutions, and even well-written Perl scripts that pull information from a content versioning system as part of device management.

My point here is not to say that separation is not important, but rather that it is likely not enough by itself to determine the SDN-ness of a particular solution.

Does Open make something SDN? No one will say that merely being open (for whatever definition of open you mean) is enough to make something SDN. The real question is whether something can be SDN and not be open. The answer here gets pretty religious, but that is largely dependent on how people have defined SDN. Can you build a software-implemented, controller-based solution that uses proprietary protocols? Absolutely. If that solution is deployed for 8 years and then the IETF ratifies a standard for the base protocol, has your deployed solution gone from non-SDN to SDN despite the lack of solution changes?


So where did all of this conversation land?

It’s not that I think there are not important principles to be considered before labeling something SDN. I just think that it is less about technology and more about context. It is absolutely conceivable to me that a particular technology can exist in both SDN and non-SDN architectures. How a protocol is used determines whether it is SDN or not. The examples are virtually endless, but I would start with things like BGP, XMPP, NETCONF, YANG, and yes, even GMPLS. Similarly, I think there are controller-based solutions that are non-SDN, just as there might be non-controller-based solutions that could be SDN.

This means that the conversation needs to move away from the technological building blocks and more to the contexts that matter. I’ll offer up three here:

  • Delegation – OSS/BSS systems have already addressed the management problems inherent in networks built from different devices delivered by different vendors. Cannot the solution simply be to implement master translators that push configuration down to however many devices? It seems to me that SDN is about removing the complexity of managing individual elements. That can only happen through delegation. Central controllers are great, but only if they can pass requirements to individual elements rather than having to manage them all in detail. The analogy I like here is one of the modern corporation. Imagine how effective your company would be if your CEO told every individual what to do. Delegation matters.
  • Abstraction – And delegation depends on abstraction. If the goal of SDN is to make workflows more manageable and networks more better (more easily managed, more responsive to applications, more intelligent, more whatever), then we need to abstract out some of the complexity. We need to work less in device-specific directives (read: configuration knobs), and more in overarching intent. The only way that different part of the IT infrastructure can ever collaborate is through a common language, and that will require abstraction. Expecting compute, storage, or applications to speak in terms of VLANs and ACLs is no more practical than turning network admins into storage or compute junkies.
  • Globality – Centralizing control is not about where software runs; it is about what that software can do. The whole premise of controller-based solutions is that having a global view of the available resources allows for more intelligent decisions to be made. If your network behaves exactly the same way with or without OpenFlow (meaning all traffic effectively uses the same paths), then does it even matter if you call it SDN or not? We need to be in the business of doing things better, not just different. And that requires globality.

These might not be the only (or even right) contexts to think about, but they at least start to frame the discussion differently. I think it is entirely possible to build open, controller-based systems that fail to deliver against any of the promises of SDN, just as it is possible to use existing technologies in new ways. Ultimately, it is the context – not the capability – that determines whether the promises of SDN are achievable.

[Today’s fun fact: A car that shifts manually gets 2 miles more per gallon of gas than a car with automatic shift. Of course all that extra work requires more sustenance, so it’s about a wash environmentally.]