MPLS: “Don’t write me off yet”

A few days ago, I re-watched the movie “Music and Lyrics”. There is an extremely cheesy song Hugh Grant sings at some point in the movie, titled “Don’t write me off yet”. I thought that if MPLS somehow could compete in “The Masked Singer”, it would most definitely pick “Don’t write me off yet” as its theme song. Yes, I am a nerd, watch cheesy movies and COVID-seclusion has made me start to pick horrible shows to watch on Hulu – I apologize. So enough about that.

Let us talk MPLS. I have known it since it was initially called Tag Switching. Then we lost sight of each other for a few years while I did other stuff, and as I moved back into networking technology, pretty much everything in enterprise wide-area networking technology revolved around MPLS. And why not? It brought true enterprise-class needs such as 5-nines reliability and deterministic QoS behavior to the IP backbones of the world, allowing enterprises to truly trust the new way of IP-based transport (not to be confused with the Internet) and obsoleting the world of leased lines (unless you have the pockets to buy dark fiber these days).

But my point is… in the SD-WAN world, it has been a hobby horse for everybody to fire big broadsides at MPLS. Here are a few:

• “It’s super expensive!”
• “It takes forever to provision and be available!”
• “It is designed to simply backhaul traffic to a central site, and that topology is completely unsuitable for cloud technology deployments!”

And while there is of course truth in those statements, I understand why many network managers still trust MPLS and, when considering a migration strategy, want to tread carefully on a safe path that guarantees success.

Let us admit it: few of us like to gamble and incur huge risk when it comes to key professional decisions, and network managers carry the burden of providing reliable and predictable enterprise connectivity that supports their businesses. While delivering on new projects faster is great, no one wants the enterprise network to go down or degrade because all hell will break loose. Let’s face it: the network must be reliable, must operate predictably and MPLS has been a proven tool to guarantee that. If I were a network manager these days, I too would take a gradual, measured, and risk-free approach when considering a migration away from MPLS. Or to put it another way, since as we work from home we’re all home network managers to a certain degree: would you immediately switch over from your current, trusted internet provider to a new provider you have no experience with simply because they promise you to reduce your broadband cost by 20%? I personally would look for a better reason, there is too much at stake since my livelihood depends on reliable internet connectivity.

Another aspect to consider is that large carriers around the world have been perfectly aware of the price pressure that MPLS premium connectivity faces. It is possible to harness great performance of (typically) redundant internet links in many geographies applying link optimization techniques. Hence, MPLS prices have come down. Clearly nowhere near internet broadband levels, the $-per-Mbps ratio is still quite unbalanced, but the price comparison is not quite as scandalous as it used to be.

But the truth is MPLS is not cloud-friendly. In my opinion, it is that, more than cost considerations, that made enterprises investigate SD-WAN and direct internet connectivity in the branch. You can look at it as a combination of cost and cloud topology support. If you choose to support cloud migration with an MPLS-centric topology, it means you would have to provision a lot more MPLS bandwidth at every site. Now that would be ruinous, so no one really tries that approach. Hence, the real killer is that MPLS imposes a centralized WAN architecture that simply is an unsuitable topology for cloud deployments. Consequently, SD-WAN delivered on the ability to break out cloud-destined traffic directly out to the public internet from the branch location. Problem solved, right?

Pardon me for being a nay-sayer. That direct break-out to the internet still poses two problems:

The first one is one we talk about a lot these days… it requires a completely remodeled security posture. We are all participating in that discussion and the entire industry now consists of enthusiastic labradoodles diligently chasing after the SASE (Secure Access Services Edge) tennis ball. There is little doubt that our industry is addressing the new security model.

But the other issue we don’t quite talk about as much is that, if you just break traffic out to the internet, hey, it may work, but it may deteriorate, and ISP SLA guarantees for public broadband are not the best. With the vast majority SD-WAN solutions, you basically outsource service guarantees two ways: (a) to be entirely reliable and deterministic, you still need MPLS; and (b) for the other stuff, you send it out to the internet, keep your fingers crossed and let one or more ISPs figure out the best route and the best way to handle the best- effort traffic you send their way. And did I mention you only get opaque visibility into either, since you do not control or have insights into the inner workings of either? That is why SD-WAN is called an overlay technology: its agility is awesome because it is based on virtualization and abstraction. Its control and visibility into or over the underlay ranges from limited to non-existent. Do not get me wrong: clearly it often works, but when it does not, you may have a harder time establishing why. You will need more capable Network Performance Monitoring tools from third party vendors, for one. In an overlay-underlay world, with virtualized resources to boot, the problem is that the last and especially the middle mile become abstracted and opaque.

Figure 1: Aryaka HybridWAN: Enabling WAN Diversity

And this is where the Aryaka architecture model provides powerful advantages:

1. There is no opacity into the first, middle or last miles. This is particularly important for business-critical applications, and the Aryaka solution provides complete, always-on visibility into network and application performance. The first and last miles operate with advanced optimization technologies, and the middle mile is provided by the Aryaka Layer 2 Global Core, which always guarantees enterprises’ subscribed bandwidth.
2. Aryaka provides a Cloud-First WAN architecture. That means that, over our global infrastructure, we provide a multitude of direct peering points to SaaS, IaaS, UCaaS services that automatically optimize the topology and provide superior end user experience.
3. We can smoothly co-exist with MPLS. The big difference is that -unlike most other SD-WAN solutions- Aryaka does not perpetuate dependency on MPLS for business-critical applications. The Aryaka Global Layer 2 Core Network provides a true alternative, providing MPLS performance levels, at lower cost, with far higher business agility and 48-hour provisioning times

But I want to point out we do not want to force MPLS migrations right away. We perfectly understand and support migration at any pace network managers feel comfortable with. What we observe is that our customers gain quick confidence in our platform, and then start to migrate away from MPLS as contracts expire at different times in different sites and geographies.

What we also observe is that in several cases enterprises still have legacy applications they are in no hurry to re-architect, and that due to regulatory requirements or perceived risk they are not willing to move away from legacy MPLS connectivity yet – so for now, we peacefully co-exist and support it, easy given our MPLS support, application identification and forwarding policies.

We live to architect for Cloud-First, but we do not live in a Cloud-Only world yet. So – MPLS, we are not writing you off yet, as the song goes. 🙂

Join me tomorrow for a short demo on our built-in support for MPLS and we can discuss this subject further in the live Q&A.