cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Do Network Engineers Dream of Software Defined Sheep?

Level 11

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.

15 Comments
Level 14

Thanks for the article.  I'd be interested to see a more in depth discussion on this topic. 

Level 20

And, of course, there's the Cisco way.  .ılılı..ılılı.

Level 11

If we accept vendor lock-in, these things are always possible... to a point. Vendors like their siloes, too. Cisco has APIC for the DC and hybrid cloud and DNA Centre for the large enterprise, but nothing to speak of for medium enterprise or pure cloud deployments. There’s lots of room for evolution even in single-vendor shops.

Level 13

Interesting Article thanks

Level 13

Thanks for the post.  It sounds great, but one wonders how long it will take for that to happen.  You'd just about have to have a single vendor architecture. No way everyone is going to agree on any sort of API that will be robust enough to actually pull of SDN in a multi vendor network.

Nope.  I don't dream of software defined sheep.  I organize my sleep patterns to dream of fishing for big ones in Canada.

(Or so I wish)

I bet Amazon and Google and other cloud-vendors of sufficient size DO dream of SDS.

Level 11

Well, it is something of a dream. I expect we'll need to compromise on a number of things to eventually get the basics. We'll have to relax a bit on the definition of SDN so that a distributed control plane works. We'll have to hack a bit on ways to make the controller talk to the end devices, though some of the white box devices may be promising there. Some of the centralized control can be attained through products like OpenDaylight, but it's definitely going to have to be built rather than purchased.

Level 11

Those folks certainly do more than dream. For networks of that scale, it's a capital "N" sustainability need rather than just a need to maximize the efficiency of the network and supporting staff. For small fish like me, I just want to be able to focus on the big picture without having to touch every little device along the way.

Level 14

Interesting... 

Question.. are "true" SDN's pipe dreams?

This is one of those situations that I think I like the "idea" of SDN/SD-WAN as opposed to the actual thing itself.  Kind of like my wife and I love cuddling and snuggling with OTHER PEOPLE'S puppies, but we're not sure we actually want one ourselves.  Lots of maintenance; taking it out to potty; vet bills, etc.  Gee, that sounds a little like SDN/SD-WAN, doesn't it?  😉

We are looking into Cisco's Viptela for remote sight, SD-WAN solution and I will be curious, when we implement it, if it will be everything we hoped for.

MVP
MVP

Thanks for the article

Level 14

They put VMWare NSX into my last place.  Now they are trapped.  It doesn't deliver what they wanted because the vendor wanted to sell something and the internal support people didn't understand it.  Now they can't start again configuring it so will have to put up with whatever mishmash was created. 

Level 11

The challenge is in finding the compromise between the ideal and what vendors’ sales/marketing engines tell us is the ideal. One is a utopia and the other is something that just tries to look like it. There’s something to be strived for in the middle, but I’m thinking that it’s not something that we’re going to be able just pull off of the shelf and cut a PO for.

Level 11

No, I don’t think so, but perhaps true SDN isn’t necessarily applicable to every network, even if the principle behind it is.

And isn't that usually the case, ghostinthenet​, that the truth/reality lies somewhere firmly in the middle.  As you alluded to, the problem exists because "reality" never lives up to the hype.  Take VHS, for instance: lesser of a technology than was BetaMax, but how many BetaMax players do you see around these days?  The "hype" of BetaMax did not keep it afloat, even though it was better.  (Now, let me qualify my previous question with the statement "I realize that I'm talking about technology that is older than a lot of folks on THWACK" but I do so to prove a point.)  Same with the original Mac: better than PC by a LONG SHOT but slower to take off, and never really did get a stronghold in business.  The promises did not deliver.  And for whatever reason, we in America seem to favor the underdog.

I certainly hope that SD-X does come into it's own because the promises of not only allowing greater flexibility and control of networks, but also taking disparate providers and bundling them together to form one, cohesive pipe to the cloud hold great potential for remote sites.  If not, though, I guess it will be another "Pet Rock"!

About the Author
Network Greasemonkey, Packet Macrame Specialist, Virtual Pneumatic Tube Transport Designer and Connectivity Nerfherder. The possible titles are too many to count, but they don’t really mean much when I’m essentially a hired gun in the wild west that is modern networking. I’m based in the Niagara region of Ontario, Canada and operate tishco networks, a consulting firm specializing in the wholesale provisioning of networking services to IT firms for resale to their respective clientele. Over my career, I have developed a track record designing and deploying a wide variety of successful networking solutions in areas of routing, switching, data security, unified communications and wireless networking. These range from simple networks for small-to-medium business clients with limited budgets to large infrastructure VPN deployments with over 450 endpoints. My broad experience with converged networks throughout Canada and the world have helped answer many complex requirements with elegant, sustainable and scalable solutions. In addition, I maintain current Cisco CCDP and CCIE R&S (41436) certifications. I tweet at @ghostinthenet, am a Tech Field Day delegate, render occasional pro-bono assistance on sites like the Cisco Support Community and Experts' Exchange and occasionally rant publicly on my experiences by "limpet blogging" on various sites. Outside of the realm of IT, I am both a husband and father. In what meagre time remains, I contribute to my community by serving as an RCAF Reserve Officer, supporting my local squadron of the Royal Canadian Air Cadets as their Commanding Officer.