Featured FutureWAN18 Tech Talks Viptela

SD-WAN Fabrics Aren’t Interoperable. Should Organizations Care?

  1. SD-WAN as a Service: Meeting Businesses at the Business Level
  2. As SD-WAN Enters Mainstream, Security Features Transform the WAN
  3. SD-WAN: When the Solution Is Greater Than The Sum Of Its Parts
  4. Moving To The Cloud – Network Nightmare or Dream?
  5. SD-WAN: Steering Apps In The Right Direction
  6. Rolling Out SD-WAN at REI
  7. Taking SD-WAN Even Wider at Acadia
  8. Treating Your Cloud Like an SD-WAN Branch
  9. Succeeding With SaaS and Viptela Cloud On-Ramp
  10. The Complex Simplicity of SD-WAN
  11. SD-WAN Changes the Internet Security Model
  12. Approaches to SD-WAN Managed Services
  13. SD-WAN Fabrics Aren’t Interoperable. Should Organizations Care?
  14. The Current State of SD-WAN in Service Provider Networks

SD-WAN is a software-defined technology that’s actually going somewhere. Interested enterprises are evaluating SD-WAN for a potentially decent ROI, performance benefits, and simplified WAN operations.

Hoping to get a piece of a forecasted multi-billion dollar market, many enterprise vendors and service providers have released SD-WAN products. At Packet Pushers, we’re tracking at least 25 different products in the SD-WAN space, and I’ve heard rumors of many more.

SD-WAN, while leveraging standardized technologies like routing protocols and IPSec, diverge under the hood. SD-WAN solutions are not interoperable. Therefore, making a product choice is risky for anyone researching SD-WAN.

Interoperability would reduce that risk substantially, and there is a movement taking us in that direction. At least, sort of. The end result is hard to predict.

The Case For SD-WAN Interoperability

At the moment, one of SD-WAN’s downsides is the commitment to the platform that’s required. With legacy WAN, it’s possible to mix-and-match routers. Any router that can forward IP and speak the right routing protocols can be used. Most organizations don’t mix and match routers, but they could.

SD-WAN solutions are not this flexible. Customers are not buying routers to build an SD-WAN fabric. They are really buying an SD-WAN fabric, only one component of which is the router. SD-WAN routers don’t function without instructions received from their central controller.

If SD-WAN solutions were interoperable, any router with the right software could be used to build the fabric, giving customers flexibility. But today, SD-WAN fabrics are not interoperable. This has been interesting for customers that won’t adopt new technology unless that technology is backed by an industry standard. SD-WAN does use a few industry-standard technologies, like IPSEC, but most of what completes an SD-WAN solution is proprietary to each vendor.

The interoperability problem brings challenges to mergers and acquisitions, too. Joining WANs is not a fun project for companies with two different SD-WAN solutions today. The fabrics can’t be integrated, so the long-term play is to choose between the two, migrating the losing fabric.

SD-WAN is ironic in that it frees organizations from service provider tyranny, only to re-enslave them within a vendor product’s ecosystem. A little interoperability would go a long way to avoiding that trap.

Emerging SD-WAN Standards & Interoperability

Plenty of sizable SD-WAN deals have closed–an estimated $861Mwill be spent by the time 2018 is over.  The Cisco-hosted FutureWAN’18 virtual conference, which I participated in as a presenter, more than doubled in attendance from 2017.

The Metro Ethernet Forum (MEF) has responded to this surge of interest in SD-WAN technology seen over the last few years. On October 30, 2018, they released a draft technical specification defining what an SD-WAN service is and what the component parts are. That’s just a first step, but it’s an important one.

The MEF is an organization aimed primarily at vendors and service providers, and not the ultimate consumers of technology. As such, the MEF’s SD-WAN standardization focus is on service providers offering an SD-WAN service to their customers. That’s good for consumers–they’ll know the SD-WAN service they’re buying conforms to a standard definition. Consider this quote from the MEF’s press release.

“MEF’s SD-WAN service definition specification describes requirements for an application-aware, over-the-top WAN connectivity service that uses policies to determine how application flows are forwarded over multiple underlay networks irrespective of the underlying technologies.”

That is a solid definition easy to agree to. However, context matters. I believe the core issue the MEF is trying to solve for service providers is different than what enterprises are concerned about. Vast service provider networks could well use multiple SD-WAN fabrics, each tailored to different service offerings. Standards can help service providers integrate those services into their massive automation system predictably.

The average enterprise is only going to need a single SD-WAN fabric. Their concern will be more about freedom of choice to build that fabric out.

The MEF’s service provider perspective is further reflected by this quote from Tim Van Herck, VeloCloud Business Unit at VMware and Co-Chair of Working Group.

“VMware believes that standardizing SD-WAN service constructs, terminology and service orchestration APIs is an important part of enabling the continued growth of SD-WAN adoption throughout the WAN industry. This is why we are proud to be an active contributor to the development of the MEF SD-WAN standard, and the standardization of the open LSO north bound APIs for SD-WAN implementations.”

See how Tim says “WAN industry” in addition to the mention of “open LSO [lifecycle service orchestration] north bound APIs”? To put it another way, the MEF work is focused on how to consume an SD-WAN service in a standardized way. This doesn’t say much about interoperability in the way that an enterprise might care about. Even so, this process gives me hope that, in the long run, SD-WAN solutions might be able to interoperate at some level.

If this happens, I suspect the process will be long. Plus, I doubt SD-WAN technology will ever consist of fully interchangeable components. SD-WAN solutions include controllers, APIs, link quality measurements, overlay and underlay routing, service chaining, and integration with third party services like public cloud networking and security. That feels like a little too much unicorn magic to standardize away.

If I’m right, that means we’re stuck with a lack of SD-WAN interoperability for the long haul.

Should Organizations Care About SD-WAN Interoperability?

I don’t believe a lack of interoperability should prevent organizations from adopting SD-WAN. The technology, despite its many proprietary implementations, has too much to offer. In addition, many companies have demonstrated that they are comfortable with some vendor lock-in. And why not? If a product is functional, meets business needs, and is well supported, then it’s an appropriate technology to acquire.

But a lack of interoperability is also a tradeoff in flexibility and independence. Once an organization is stuck into an SD-WAN fabric deployed at hundreds or thousands of sites, it will be hard to walk away from it. Even if the MEF standards do make things a bit easier in the coming years. There’s always a tradeoff.

If you would like to watch the FutureWAN panel that discusses these topics and more, please register for SD-WAN Conversation Between Service Provider and Enterprise here: https://vshow.on24.com/vshow/sdwanapac/content/1906830/

About the author

Ethan Banks

Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 1M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction.

Leave a Comment