SDN Focus is brought to you in partnership with:

Michael Bushong is currently the vice president of marketing at Plexxi, where he focuses on using silicon photonics to deliver SDN-based data center options. Mike is a DZone MVB and is not an employee of DZone and has posted 130 posts at DZone. You can read more from them at their website. View Full User Profile

SDN, Network Packaging, and Separation of Control and Forwarding

03.19.2014
| 3568 views |
  • submit to reddit

It’s not clear to me whether there is really a conclusion to a technology trend. I suppose that one trend begets another and that morphs into another. So in some sense, discussing the SDN end game is really foolish. It seems most likely that we all stop talking about SDN in another year, maybe two, and the conversation returns to networking. Or data centers, or the WAN, or whatever. And then eventually we talk about IT infrastructure, because it will ultimately become so integrated that calling out isolated elements will seem old-fashioned.

That said, let’s talk about the SDN end game a little…

For many, SDN is about separating the control and forwarding planes. I’ll just point out that these planes have been separate for years in most modern networking equipment. That they might no longer be distributed within the same sheet metal is interesting but not really that game changing. I don’t mean to suggest that there is not value in changing the packaging (a la what Cumulus is doing), but there is nothing inherently good or bad about packaging. The Cumulus value proposition (as it relates to physical equipment costs) is that they will charge less for the software than the big guys have been so far. [Lest this be perceived as a slight, I believe this to be a valuable thing to do. I like what these guys are doing, and how they are doing it is very crafty.]

The big players already skew their R&D costs towards software. That they capture dollars via the hardware simply reflects the buying culture. Imagine that all the major equipment vendors dropped their hardware prices are started charging more for software (which is typically free or discounted to zero in a normal purchase). The difference between Cumulus and the rest would be that Cumulus is charging less for the software.

Part of this is because there is less software there. If we are honest, part of Cisco’s pricing premiums are tied to the 47 thousand features that come with an IOS (or IOS-XE, or CatOS, or whatever) device. So long as those features are important to you, you have to pay the premium because there is only one vendor in the world who has them. Again, this doesn’t make Cisco inherently good or evil – it just means they have priced their product according to demand.

What is really happening with SDN (and with Cumulus in particular) is that people are contemplating for the first time in a very long time new architectures. Those new architectures are somewhat less dependent on the history of networking features. To a large extent, the industry is going on a feature diet. The result is that there are now more commercial options because the foundational feature set is both smaller and different.

If the feature set is smaller, the premium that people are willing to pay is lower. And for companies building from scratch, the effort (read: development cost) is lower. They can charge less and still be whole. When you add in more mature open source options for what have typically been the networking staples (routing protocols, for instance), the barrier to entry for new networking solutions has never been lower.

Oddly enough, the biggest thing standing between customers and lower prices in this case is the customers themselves. Those that are willing to adopt a new Ground Zero for feature completeness will essentially create more choice and flexibility for themselves. They can use that, in part, to get better pricing advantages.

Note that none of this has anything to do with whether the control plane runs on an x86 inside the sheet metal or outside. That’s just a distraction.

So if SDN isn’t about the packaging, what is it about? There are a hundred thousand definitions, but the real pain point being addressed is work flow. The reason the network is so difficult to manage is because it relies on pinpoint precision on a box-by-box basis. Fine-grained control over the policy that drives network behavior is extremely powerful, but that power comes at a cost.

For most people, the choice between power and ease of use was never really a conscious one. We were collectively sold on a set of reference architectures and best practices. In the early days, this was exactly what everyone needed. The problem is that inertia is ridiculously strong, and once the decision to manage through pinpoint, manual control was made, it was never really revisited. Customers demanded more precision (read: configuration knobs or protocol extensions), and this shaped the way the entire industry evolved. The price of admission into any network was a set of features. Only a few companies could provide these, and so the options remained few and the prices stayed high.

How do you combat this dynamic?

SDN needs to be about moving from knob-based behavior specification to something that is more automatable. The only way to be more automation-friendly is to be less device-specific, and that begs for abstraction. Once you abstract out the devices, the edge policy isn’t as tied to the underlying hardware. This means we can more easily separate the control and forwarding planes. Oddly enough, this means that the initial desire for SDN to be about separation is actually somewhat correct.

The problem with starting at that point, though, is that people miss a whole lot of the in-between stuff, and it’s those icky details that will ultimately determine success or failure for people pursuing a new way of doing things.

[Today's fun fact: When Albert Einstein died, his final words died with him. The nurse at his side didn't understand German. <Insert Der Wienerschnitzel joke here>]

Published at DZone with permission of Mike Bushong, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)