Americas

  • United States
Contributor

Carrier SD-WAN: SD-WAN should be more than just an MPLS complement

Opinion
Mar 22, 20184 mins
NetworkingSD-WANWAN

Simply put, enterprises should be able to abandon MPLS when they have a better approach.

SD-WAN
Credit: istock

Is it only me who finds it just a bit dubious that carriers are advocating SD-WAN? SD-WAN was practically invented to get away from the clutches of carriers, and now we’re supposed to trust them to be the stewards of WAN transformation?

Carriers lost that privilege when their business model grew out-of-step with how we do business. We grew tired of being charged double Internet prices for MPLS capacity. In an era of self-service, carriers were still making us wait to troubleshoot problems. And we were astonished that new MPLS circuits could take weeks, even months, to bring into a new site when you could often get started with broadband in a matter of days and upgrade to DIA when ready.

Carriers seem to look at SD-WAN as just another tool for keeping customers on MPLS. As Shawn Hakl, senior vice president of business products at Verizon, noted in this interview, customers aren’t replacing MPLS with Internet, they’re adding SD-WAN: “What we see is a lot of MPLS plus LTE backup,” he told SDXCentral.

It makes sense. After all, the revenue carriers see from an SD-WAN-over-the-Internet contract is a fraction of an MPLS deal. That’s usually a big disincentive for delivering SD-WAN without MPLS.

Over the years, my experience has been that carrier teams do their best selling with what’s been lucrative and known —  capacity. Have locations that need to be connected together with their lucrative MPLS or leased line services, and carrier teams will have all the right answers. Do something a bit different and that’s another matter. The latest example came this past week.

The IT team at one of my Fortune 500 customers was evaluating SD-WAN services for its global network. The team was leaning towards an independent, secure SD-WAN provider when an executive pushed to evaluate the SD-WAN offering from one of the major carriers. He was more “comfortable” with an established provider than a young company. The team consented and invited the carrier in for a meeting.

From the outset, things were off. The carrier’s sales team couldn’t answer some basic questions about the SD-WAN equipment and firewalls they sold. Fast forward to a Proof of Concept (POC) when they eventually received the hardware, the carrier sales engineers couldn’t configure the SD-WAN appliances properly. For a week, they worked on the issue until bringing in the SE from the appliance vendor who got it to run in an hour.

But before that happened, the sales team had punted to another team who misstated the customer’s requirements, proposing a secure web gateway (SWG) to supplement the SD-WAN and its integrated firewall. Apparently, the initial intake was poorly executed, and the team failed to communicate the proper customer requirements to the new group. This required a complete rehash of our introductory meeting.

Carriers still seem to work at a different speed than today’s business. Another client I had was told by their carrier they could start a Proof of Concept (POC) in just two or three weeks. After engaging with them, it ended up that the carrier would need 90 days just to get the hardware. Why? Because, apparently, sales didn’t provide all of the necessary information, namely the public facing IP address the SD-WAN appliances would need to pull down the configuration profiles for installation and setup of appliances. There simply was not adequate communication among the carrier’s staff.

And once you sign with a carrier, the same kind of process and overhead continues to be a problem. Carriers need time to receive equipment from their suppliers which further delays deployment. How long? One product manager at a major U.S. carrier told me that while they have CPE inventory, they require at least eight weeks to restock that inventory. Which raises the question, “if a bunch of different carrier customer installations implemented at once, will you be a victim of no more inventory?”

A two-month window can make an awfully big difference for the bottom line. By switching from MPLS to a hybrid configuration, another customer of mine was going to save $5 million a year. Delaying that transition by eight weeks would mean paying $770,000 in MPLS and management costs alone.

There’s no reason why that should be the case. SD-WAN was a technology designed to be deployed in minutes not months. Yes, MPLS can and often should be part of a hybrid WAN today. But over the long term, enterprises should be able to abandon MPLS when they have a better approach. Simply using SD-WAN to lock enterprises into MPLS, isn’t WAN transformation. It’s just perpetuating the same WAN and carrier problems we’ve always had.

Contributor

In 2007, Steve Garson started SD-WAN-Experts (at that point called MPLS-Experts) to help U.S. companies communicate with their Chinese and Indian manufacturing facilities. Two clients were rolling out their ERP systems in China and found that their new networks were impeding operations, an unexpected and undesirable problem. A quick examination identified their VPN over Internet as the root cause of the unacceptable performance they were experiencing.

SD-WAN-Experts helped them install a high quality MPLS network to eliminate the packet loss and reduce the latency that is found on the internet. This led to quickly realizing that many other U.S. companies were having the same problem; or they were using less manageable frame relay or point-to-point circuits. Thus, was born this specialized practice in consulting to companies on the procurement and roll-out of Wide Area Networks (WANs). SD-WAN-Experts now serves companies worldwide with global facilities, large retail chains, as well as small domestic companies, and has even designed government emergency communication networks for an entire state.

The opinions expressed in this blog are those of Steve Garson and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.