Opinion: Do You Care about MPLS in 2022?
One of my readers asked for my opinion about this question…
… and I promised something longer than 280 characters.
There seem to be two correct answers to this question:
- I don’t think that word means what you think it means
- It depends
Let’s start with the first answer.
What Does MPLS Mean?
For whatever reason some people understand MPLS to mean MPLS/VPN-based layer-3 connectivity services delivered by a service provider1, in which case “do you care about MPLS?” should really be “are you buying/using MPLS/VPN services?”. That’s an easy question – as I explained last week, MPLS/VPN is unnecessarily complex (for a mix of good, bad, and ugly reasons), and so I’d prefer using anything else that meets the requirements2.
As always, there are exception to every rule-of-thumb:
- MPLS/VPN could be the only reasonable service you can get.
- MPLS/VPN could be way more reliable than Internet access3.
- IP routing (MPLS/VPN) is a better option for low-speed or high-latency links than bridging (Carrier Ethernet). I haven’t seen Carrier Ethernet over Frame Relay or satellite links yet.
- You might need two providers for resiliency/business continuity reasons, and combining a fast-and-cheap Internet uplink with a slower, more expensive, but a bit more reliable MPLS/VPN one is not a bad idea. If you can afford it, use both as pure IP transport, and add routing over tunnels on top of that IP transport (see also: DMVPN or SD-WAN).
- Your purchasing team just signed a 10-year contract to get a 3% discount
- Add your own reason in the comments ;)
Who Uses MPLS?
On the “do you care about MPLS as technology” front: regardless of what the SD-WAN pundits are telling you (because they belong to the “MPLS doesn’t mean what you think it means” crowd), MPLS encapsulation is one of the most elegant encapsulations out there, and the idea to classify traffic at ingress and use labels to indicate the Forward Equivalence Class (FEC) and/or egress next hop is still perfectly valid.
We should also distinguish between the data plane mechanisms (encapsulation and label switching) and the control-plane protocols4. LDP is slowly going away in favor of SR-MPLS control plane mechanisms (IGP, BGP, PCEP…). L3VPN might be eventually replaced by EVPN (but not any time soon), but wherever the bandwidth is expensive enough (example: outside of the data centers), the underlying encapsulation is still predominantly MPLS.
Now that we got the pedantry out of the way, let’s see who (still?) uses MPLS technology in 2022. I don’t think that landscape has changed significantly in the last decade.
Many large service providers use MPLS-based solutions internally to:
- Build BGP-free core
- Implement traffic engineering
- Have fast reroute capabilities, either using MPLS FRR, remote LFA or Topology Independent LFA
- Build services on top of MPLS transport (even Carrier Ethernet is often implemented on top of MPLS)
- Increase the utilization of their peering links with Egress Peer Engineering.
- Add your favorite use case in the comments.
I know enterprises that had to build their own multi-tenant VPN infrastructure, and used MPLS/VPN instead of the SD-WAN pixie dust. If you want to have a standard-based architecture, MPLS/VPN is still the best way to do it.
Finally, even some hyperscale web properties use MPLS encapsulation to steer traffic from their web proxies to the optimal egress link (similar to Egress Peer Engineering).
Whether you care about MPLS (the technology) in 2022 thus depends on the environment you’re working in, but it’s alive and doing quite well in many large-scale environments.
For a deep dive into “that is not what MPLS means”, read the You’re Probably Using The Term MPLS Wrong by Chris Parker. ↩︎
Keeping in mind that Carrier Ethernet is WAN bridging in disguise, so be careful how you use it. ↩︎
I’m not saying that applies to your residential Internet circuit, I’m just saying that the future is not evenly distributed, and there are still pockets of abhorrent connectivity. ↩︎
Should we call control-plane protocols needed to support MPLS encapsulation “MPLS”? I don’t think so, we should be more precise. ↩︎
Thank you very much for this post.
For those not directly involved in the market, it is difficult to determine when a given technology is not "sexy" anymore. Some technologies are mature and still alive, some of them are legacy technologies that only persist in niche domains, and some others never flourished or have been completely superseded by another technology. However, most of them are thoroughly described in the textbooks and/or the Internet (The Internet is dark and full of terrors), to the very last header bit, but without any actual information about their fate or demise.
There are many other technologies (which, in many cases, are still taught at Universities, because books) in which similar posts would be very appreciated. For example, a quick brainstorming going back many years:
When was X.25 official declared dead? Note that the wikipedia claims that it is still in use in parts of the world. What about FR? ATM? ...
You mention MPLS/VPN and SDWAN, what about other technologies? Is people still using IPSec/TLS tunnels? DMVPN? FlexVPN? ...
Are FabricPath, TRILL or SPB still alive, or has everyone moved to VXLAN? Are they worth studying?
Regarding storage, is Fibre Channel still a thing in 2022, or most people employ SATA over Ethernet and NVMe over fabrics? What about SAS drives, do they still make sense other than in legacy arrays, or has their segment been completely hogged by NVMe SSDs? What about FCoE? Note that FCoE is still part of Cisco's certifications, but I have seen many posts declaring it dead 7-8 years ago.
I know that some information can be obtained from market analysis firms (such as IDC) and that you have posts about some of the mentioned technologies. My point is not so much to ask specifically about each of them, but rather to highlight the lack of available up-to-date reliable information about the status of many technologies.
TRILL more or less died a while ago. The notion of TRILL interop died really early on with each vendor doing their own control plane or data plane shenanigans.
SPB more or less is gone too. From my perspective, when I was working with it, it was a beautiful story for campus networks. Stretch bridging domains strategically where you needed, keep backbone MAC tables clean and stable, and get simple L3VPNs.
Avaya and Alcatel-Lucent were the only ones truly investing in it (SPB-M) from what I could tell. A few others like Enterasys were along for the ride (doing SPB-V). Avaya had the best story with very simple configuration, L3VPN support, and they even transparently implemented the loopbacks needed to deal with packet recirculation -- same problem most vxlan implementations had when implementing symmetric IRB in EVPN. You didn't even see that was happening in the config -- the loopbacks were hard wired, though you could never get them to actually tell you how much bandwidth was dedicated to it. Alcatel-Lucent-Enterprise made you install a loopback cable and a small pile of config to patch things together yourself.
At any rate, the whole routing-in-and-out-of-tunnels thing I think really hampered SPBs its momentum. In the meantime, VXLAN (even with flood-and-learn forwarding semantics) gained popularity.
Fast forward to today and I don't think much is being done with SPB. I've implemented SPB (ALE's version) and it was OK. VXLAN-EVPN has a lot of promise but I can't see a campus network using it very often. There are too many knobs and too much config for limited gains. And hardware that has RIB/FIB space for a large campus gets pricy to run EVPN down to the access switch.
That's the part I think we might have lost as an industry -- getting PE-like functionality down to the smallish scale, like access switches. It has its flaws and limitations but so does anything else.
I might also just be romanticizing about what could have been ;-P Markets rarely pick what's best and rarely is the definition of "best" consistent across businesses anyway. Still - I wouldn't consider SPB today any more than I'd consider using ATM or flow based forwarding (sorry LISP)
"PE-like functionality at smallish scale" is a decent description of what we're trying to do with SR Linux.
We are definitely not there yet, and would welcome any feedback.
Regards, Jeroen van Bemmel (Nokia)
"I am biased therefore I am"
An interesting read like always, thanks you for continuing to publish quality material. Coincidentally, Chris Parker published an extensive post about the same subject just yesterday. It's aimed at a bit more junior readers than your visitors probably, but still interesting as another take on the subject: https://www.networkfuntimes.com/youre-probably-using-the-term-mpls-wrong/
Kind regards, Jaap de Vos
Thanks for the link, added a footnote.
On a "there really are no coincidences in this world" note, I've seen his blog post this morning, emailed myself a link so I won't forget to add it, and went climbing. When I got back home, I had three pointers to Chris' blog post in various places ;)
My take. Different technologies for different times. MPLS had its time and is still relevant in the core but it has no relevance at the Enterprise Edge.
MPLS was dressed up as an L3VPN (2547 anyone?) and successfully sold to enterprises for 20+ years. SD-WAN (at least 1), supersedes anything that L3VPN has to offer. I'll start with first-mile protection i.e. SD-WAN from the branch, vs MPLS from the PE/POP!
Sorry to say but if MPLS, as an enterprise offering, were a dinosaur then MPLS is Chicxulub T+ several years. The Enterprise version of the MPLS sun has well and truly set.
P.s. I believe Ed Sheeran as did the judge this week ;-)
I'm torn on this subject and still have much love for MPLS. I see modern day use cases (SP, large enterprise, etc), but also see MPLS as evolving into something like EVPN in the future. That said, the DP side of MPLS is still a very elegant and ubiquitous solution. The CP side of MPLS is moving towards SR which is very positive trend. I predict that MPLS will still be a major part of transport networks for the next 5-8 years.