Let’s Talk Simply About SD-WANs, Shall We?

If “talk nerdy to me” were to be elevated to an art form, then at Cisco, we’re Rembrandt! Following a recent article suggesting that our naming convention(s) for our line of Software-Defined Wide Area Networks (SD-WAN) is confusing — I’d go so far as to say “drowning in six-letter acronyms and Dilbert-esque techno-jargon,” — I would like to take the opportunity to simplify things.

I use the Dilbert reference deliberately. I never worked at Pacific Bell, but I know my way around things like ISO-9000 pretty well, and I’ve certainly worked in a few cubicles. Having joined Cisco in 1998, I even know somebody who knows somebody who knows Alice (pretty sure), who, if you didn’t know, is based on a former co-worker of the cartoonist. (Her claim to fame at Pac Bell was “making grown men cry at meetings.”) She left Pac Bell at some point, to work, where? If you guessed Cisco, cheers to you!

Indulge me this humble attempt to untangle the terminology that can indeed be a jumble, what with SD-WANs, I-WANs, ISRs, MPLS, APIC-EMs, NSOs, and E-I-E-I-Os. (Ok, that last one was a throwback to old MacDonald and his farm.) Note: I plan to go at this from a “why” perspective, rather than further confusing the issue with more product jargon.

It is correct that we are currently partnered with four service providers to provide SD-WANs, to their business customers.

Those service providers, and likely every entity like them, exist along a continuum of the massive digital and IP transformation happening in networking technologies. What they need, and routinely ask for, are choices. A “mix-and-match” solution roadmap. That way, they can satisfy current businesses, while economically growing their future telecommunications needs — for their customers, as well as for themselves.

If follows that when considering the SD-WAN vendor landscape, service providers generally seek mix-and-match SD-WAN solutions. Again, so they can optimize how they provide bandwidth and telecom services to their enterprise customers, as well as their own operations.

From an operations perspective, for instance, SD-WANs are particularly of interest in branch offices. (The mention of some customers looking for WAN optimization to move traffic from MPLS — Multi-Protocol Label Switchers — to lower cost connections? Spot on.)

That’s because statistics show that some 90% of enterprise revenue happens at branch offices, and that 80% of employees work at those branch offices, according to research from Tech Target and the U.S. Census Bureau. But what happens when work-at-home staffers come in for a week, or when video conferencing and mobile/WiFi traffic picks up (which it is expected to do, at a very rapid rate)? More than half (60%) of WAN budgets are expected to stay flat, according to Nemertes Research.

As a result, a big part of network strategy for service providers is to make those branch services more efficient, with a consistent user experience, no matter the traffic ebbs and flows. (I’m trying to do this without wallowing too much in my comfort zone — tech talk — but that’s where the I-WAN term comes in, where the “I” stands for “Intelligent.”)

As far as controllers go, the mix-and-match of it goes like this: Some enterprise customers prefer more of a “DIY” environment, where they’re in charge of the end-to-end. Those customers generally go for our APIC-EM (which stands for “Application Policy Infrastructure Controller – Enterprise Model.”)

Others prefer more of a managed arrangement by their providers, with tools & portal that simplify the process of service provisioning and brings in automation of connecting or removing devices at different branches. That’s where our Network Services Orchestrator (NSO) comes into play.

Here’s the thing: The two approaches are not mutually exclusive. Roll your own, or take the full suite — it’s a matter of choice.

Another observation in the article suggested that part of the reason for the nomenclature complexity stems from the fact that we’re fashioning our SD-WAN line with existing products — rather than building from scratch, “like many SD-WAN vendors.” Again, here’s the thing: If you’re a service provider, the whole “building from scratch” thing can be intimidating.

Why, because they’re upgrading for SD-WAN and its offshoots with the same solution set we’re building out from — and which we co-developed, over a matter of years, to include the needed suites of interfaces, protocols, and security measures that have held them in good stead. Starting from scratch introduces inevitable potential to “miss something” which becomes customer- or operations-impacting. Usually not in a good way.

I appreciate how much tech-talk can make one’s hair hurt. I used to say that tech talk sounds nerdy because we engineers tend to name things for what they do, but even that is getting less obvious in the all-digital, all-IP, all-software world.

And with that I conclude this network-wade into the tech-talk of software-defined wide area networks. I thank you and the fine folks at SDXcentral.com for shining the light on what’s going on in our world of SD-WANs, however complex. Hopefully this helped clear it up!