Why MPLS/VPN Services Will Become Redundant, Replaced By SD-WAN With Internet Transport

October 11, 2018


Software Defined WAN, or SD-WAN for short, is the ‘new kid on the block’ and is becoming a big thing in the world of networking. There’s a huge rush right now from the following industry players to get in on the action:

  • Analysts (like Gartner, etc.), who predict dramatically increasing revenue potential;
  • SD-WAN vendors, who are outlining huge benefits from SD-WAN, including the opportunity for significant ‘cost savings’;
  • Service Providers, whose aim is to play down the potentials of SD-WAN and ‘prove’ that MPLS will work just fine long into the future; and
  • Systems Integrators, who are pushing all the above agendas to make new sales.

Of course, with such a major industry transformation comes differing levels of interest, business requirements, technical knowledge, and experience on both the Enterprise and Service Provider side. Therefore, we’re witnessing a wide variety of marketing and semi-technical publications, blog posts etc. with headlines such as:

  • “SD-WAN vs MPLS” or “SD-WAN is the Death Road for MPLS”.
  • The 5 or 10 Myths about SD-WAN
  • Etc, etc.

As a potential customer, it’s hard to know whose opinion to trust and how to cut through this hype so you can make practical progress with your SD-WAN project and choose the right partner. I’d like to open your eyes to why I believe MPLS/VPN Services will soon become redundant and will be replaced by SD-WAN with Internet transport, and therefore why you’d be better off working with an SD-WAN MSP as opposed to a Service Provider in the long-term. I encourage you to keep an open mind as you read through my opinions, and I welcome you to get in touch with me if you’d like to carry on the debate!



Let’s start with the SD-WAN vs MPLS argument.

First, I’d like to tell you that SD-WAN should not be compared to MPLS, because they’re fundamentally two completely different technologies.

SD-WAN is an L3 Overlay (like L3 IPSEC VPN), and MPLS is a L2 Transport technology operating in virtually all Service Providers’ core networks. A more appropriate comparison would be SD-WAN vs IP MPLS/VPN, or more specifically, the VPN service that Service Providers provide using IP MPLS/VPN technology.

From a technical point of view, most of the Service Providers have an MPLS Core, and then provide assorted services based on MPLS/VPN technology. Even their Internet (DIA-Dedicated Internet Access) services are provided using L3 MPLS/VPN technology over an MPLS Core (see Note #1 at the end).

The SD-WAN vendors are saying they’re going to “kill” MPLS. I’d advise caution here, because it’s not a case of the SD-WAN vendors replacing MPLS, but more that they’ll replace the need for MLPS/VPN Services (offered by the Service Providers).

I believe the reason many of the SD-WAN vendors have taken the approach of comparing SD-WAN to MPLS is simple – they’re trying to tell us that MPLS is in fact MPL$, and by moving to SD-WAN you can remove a lot of $$$ from current Legacy WAN networks.

At the same time, I read in one Service Provider blog that saving costs by implementing SD-WAN is the #1 myth. Of course, it’s obvious that replacing a single line MPLS/VPN service with SD-WAN and a single Internet connection is not a good idea, but, replacing a single line MPLS/VPN service with SD-WAN and 2x Internet connections (from different providers) is a GREAT idea! And I can state with confidence that this type of branch connectivity will perform way better and much more reliably for a fraction of the MPLS/VPN cost.

With many things in life, the truth is usually somewhere in the middle. Not this time, in my view. SD-WAN can replace the Legacy WAN and save you money, PERIOD. But you need to understand Why, How, and What needs to be done to achieve these savings. Our SD-WAN Workshop can help you with that.



Next, I’d like to define in very simple terms what an SD-WAN can do differently and better than a Legacy WAN network. These are just a few key points to consider. SD-WAN’s:

  • Can operate over any type and combination of links (transport) to the branch. Your MPLS/VPN, Internet (DIA), DSL, 4G/LTE etc. Branch connectivity simply becomes ‘transport links’.
  • Can easily run all the links in Active/Active mode or as a single ‘bundle’.
  • Have Application Aware routing, so can be optimised to steer or re-direct any application traffic DYNAMICALLY over any transport link based on pre-defined rules (SLAs).
  • Are very secure, because all traffic is fully encrypted. Customers’ prefixes and routing aren’t controlled by the Service Providers and are ‘invisible’ to them.
  • Routing and policies are centrally controlled so the network is extremely agile and dynamic.

The above are each very important features and capabilities of a Software-Defined Network and cannot easily be implemented using Legacy router technology. Even if it’s possible, it’s so difficult to design and implement that very few (if any) Service Providers are delivering it.

SD-WAN features (the likes of Forward Error Correction (FEC), per packet Load Balancing, Performance Aware Routing, etc.), can make Internet links perform extremely well. For example, SD-WANs can easily compensate for more than 2% packet loss (with FEC). Therefore, SD-WAN branches with 2 or more Internet connections (Consumer or Business grade) will outperform the Legacy router-based branch with MPLS/VPN links in any ‘department’. This is something I’ve witnessed many times and is the norm.



So yes, in a way, SD-WAN can save costs, but is this the most important benefit? Is it the main thing that’s driving companies to start an SD-WAN technology evaluation? The answer is most definitely NO, and here’s why:

  • IP MPLS/VPN Service architecture is designed to provide private communication between branches and the Data Centre and/or Enterprise Headquarters. All applications and data used to be in the Data Centre or Headquarters – however, most of today’s applications and data are migrating (if not already migrated), to the Cloud, be that public and/or private Clouds. Microsoft Office applications have already been moved out from almost every Data Centre (i.e. O365). This behaviour drives the network to require a completely different architecture. Branches should now be able to communicate and send most of their traffic over the Internet to the various Cloud Gateways. Backhauling that traffic via MPLS/VPN and via a few Internet Gateways is almost like ‘Blackholing’ it.
  • MPLS/VPN Networks are ‘private’ according to the standards from the Year 2000 and it’s a secure-enough comparison with ATM/FR (if anyone still remembers this technology), but, this is neither private nor secure for today’s requirements. Why not?
    • The data ‘travels’ across the MPLS network unencrypted or as ‘clear text’. The Service Providers can (I’m not saying they will do this by the way!) easily ‘mirror’ the port on the PE and then see all the customer’s traffic.
    • The customer routing information must be exchanged between the CE and PE; therefore, all the customer’s routers are in the PE’s private VRFs. Unfortunately, if the Service Provider makes a mistake, these prefixes can easily become part of some other customer’s VRFs.
    • I’m not sure how GDPR compliance and requirements will be delivered over an MPLS/VPN service. Enterprises may be forced to use 3rd party solutions to deliver encryption in transit.
  • An MPLS/VPN Service isn’t agile enough for today’s requirements. Sometimes it can take many weeks/months to implement a new MPLS/VPN service, therefore you have to wait a long time if you want to open a new branch office or move the existing one. Opening a ‘temporary’ type of branch is almost impossible with an MPLS/VPN Service.

When enterprises implement an SD-WAN network based on the hybrid model (MPLS/VPN and Internet links to every branch), they’ll see very quickly that most of the traffic uses the Internet links. The simple reason for this is that the Internet links will typically have much bigger bandwidth and provide much better performance to the applications in the Cloud. As a result, the MPLS/VPN links will have very little utilisation, and I predict they’ll become completely redundant.



I’ve witnessed the following scenarios multiple times in the last few years:

Enterprise customer: “Please provide me with an SD-WAN cost, so I can convince my Service Provider to slash our MPLS/VPN prices”.

Service Providers: “We’ll be happy to drop our prices as long as customers stay on our MPLS/VPN service”.

This is what I call a ‘Lose-Lose’ situation!

Here’s why:

  • The customer will probably achieve a 30%, maybe even higher, reduction on MPLS/VPN service prices. Unfortunately, sooner or later the customer will realise that most of their applications and data have been migrated to the Cloud, therefore, most of the traffic will need to go directly over Internet links. As a result, MPLS/VPN links will become under-utilised, or redundant, and will basically become very expensive, whatever price the customer is paying. The customer will face all kinds of problems: from performance routing and security, through to agility and the need to open new branch offices rapidly. Customer networks with outdated WAN architectures (based on MPLS/VPN Services) will not be competitive, therefore reductions in business productivity and profitability could be significant.
  • Service Providers will be happy to take a ‘hit’ on some of their MPLS/VPN revenue but will keep customers for another 2-3 years – a reasonable trade-off for them. Unfortunately, 2-3 years later, and assuming they’re still in business, all customers will end up leaving the MPLS/VPN Services in an avalanche fashion. I believe Service Providers will therefore have to transform their businesses ‘in a hurry’, delivering not only new services, but also management of those services. Practically, it will be too late for them to act and they’ll simply become ‘Transport/Bandwidth providers’ or an easy and cheap acquisition target for the OTT Players.



So, if that next, logical step is to transition to become a provider of SD-WAN Services, what predictions do I have for you in that space? Here’s what I think:

  • MPLS/VPN Services will become redundant based on my comments above. MPLS and MPLS/VPN (L3 or L2 VPN) as a technology will stay for a considerable length of time (there’s no other technology on the horizon to replace them), but the MPLS/VPN Services will disappear.
  • Enterprise customers will take back control of the WAN. SD-WAN technology will move WAN control from the Service Providers back to Enterprise customers. They’ll control the routing (based on performance), the security, the topologies, etc.
  • The ‘migration’ from an MPLS/VPN-type service to an SD-WAN service will not be like the migration from ATM/FR to an MPLS/VPN Service as providers had to ensure 15 years ago. SD-WAN services and benefits are all about the Edge node, therefore there are very limited benefits to a Service Provider in implementing SD-WAN on their own infrastructure.
  • Service Providers will lose control of Enterprise WANs and will become Transport Providers, providing mainly Broadband-type Internet transport and very limited MPLS/VPN (L2 or L3) Services (more likely to be MPLS/VPN Transport).
  • There’ll be a new class of Service Providers: SD-WAN Managed Service Providers (MSPs). Many Enterprise customers have network skills shortages and will need to ‘outsource’ the management and maintenance of an SD-WAN to an SD-WAN MSP.

There are two distinct SD-WAN MSP delivery models:

  • Telco or carrier-based offerings (BT, AT&T, etc.)
  • ‘Over the Top’, or OTT offerings (Teneo, Coevolve, etc.)

The main difference between the two is the ownership of the transport: is the SD-WAN MSP provider an owner of, or invested in the transport, or not?

One of the requirements for the MSPs will be to deliver a ‘Transport Independent’ solution for their SD-WAN customers. For example, they have to use 2 or 3 different MPLS/VPN providers as well as many ‘local’ Internet Broadband providers. They’ll also need to evaluate the performance (SD-WAN gives you a lot of tools in this area) of each transport type and be able to replace the under-performing links very quickly.

To me, it seems obvious that if the current Service Providers (the likes of BT, AT&T, etc.) become the SD-WAN MSPs, they’ll have significant conflicts of interest, so perhaps they’ll have to set up their MSP division as a totally separate company/entity. Time will tell.



Here’s what I’ll leave you with.

The migration of applications to the Cloud is already dramatically changing traffic patterns. Migrations of O365 to the Cloud are pushing a lot of traffic from the branch into DIA links.

My opinion is that SD-WAN with Internet Transport will replace MPLS/VPN Services, not because of the cost. If cost is the main issue, then Service Providers and Telco’s can resolve that issue easily, by reducing their prices.

The bottom line is that an MPLS/VPN architecture is the wrong architecture for today’s cloud applications, therefore MPLS/VPN Services will soon become redundant. This will make DIA transport (with SD-WAN technology behind it) the main transport for corporate WANs.

MPLS/VPN should only be used as a transport method during the full transition to an SD-WAN network over Internet transport. Therefore, in my opinion, Enterprises shouldn’t commit to buying private MPLS/VPN Services and bandwidth in the long run.

My final remark is that Enterprises investing in SD-WAN technology to achieve the best price vs performance with ‘real’ SLAs (even based on applications) must partner with the new SD-WAN MSPs, which are TRANSPORT INDEPENDENT!

If that’s you, please feel free to get in touch with me at rdoukov@teneo.net to talk through your requirements.


Note #1: Service Providers delivering MPLS/VPN services and Internet services are physically using the same PE nodes and the same MPLS Core. So why is MPLS more expensive or more ‘reliable’?

It’s because it’s a managed service with guaranteed QoS over the MPLS core. As Internet services are already becoming more important for Service Providers, it becomes a lot more reliable. Internet quality has become increasingly better. Broadband availability, speed and quality continue to grow in almost every geography. There are also many country-level, regional and other geographical Internet peering exchange points.

Based on today’s high-bandwidth application demand (video content, etc.) as well as cloud adoption, bandwidth growth is exponential and predominantly on the Internet side with very little on the private MPLS/VPN side.



I have over 30 years of networking and communication technology experience working for Vendors, Systems Integrators and Large Service Providers covering a large range of networking technologies. As a Lead Solution Architect, I have designed and delivered networks ranging from small TCP/IP router-based networks, to very large MPLS (Core, Metro; VPN’s, Internet) Service Provider networks.

Technology transformation has been a primary part of my responsibilities as a Lead Solution Architect. This includes large transformation programmes for Next-Generation IP/MPLS (from ATM/FR), Cloud and Data Centres, Internet Peering and SDN/SD-WAN technologies. I possess an in-depth knowledge of technologies in specialist areas such as SDN/SD-WAN/NFV, IP/MPLS, Data, Voice and Video Integrations, Cloud and Data Centers. You can contact me at rdoukov@teneo.net



Most IT Infrastructure and Operations teams are overworked and struggle to introduce new technology. At Teneo, our Work From Anywhere IT services combine leading technology with expert guidance, so you can embrace innovation with confidence. Find us at www.teneo.net

Contact us - We’d love to help you

    Teneo collects your personal data when you complete our online forms. We will use this information to provide an accurate response to your questions or requests and we will keep a record of your form completion in our CRM system. By submitting this form, you agree to us contacting you for the purpose of our response. For more information explaining how we use your personal data, please see our Privacy Policy.