Reaction: The End of MPLS?

Jason Wells, over on LinkedIn, has an article up about the end of MPLS; to wit—

MPLS, according to Akkiraju, is old-hat and inefficient – why should a branch office backhaul to get their cloud data, when Internet connections might be faster – and 100X cheaper? Cisco, in acquiring Viptela, has brought Akkiraju, his company, and his perspective back into the fold, perhaps heralding the beginning of the end of Cisco’s MPLS-based offerings (or at least the beginning of the end of the mindset that they should still have an MPLS-based offering).

To being—I actually work with Aryaka on occasion, and within the larger SD-WAN world more often (I am a member of the TAB over at Velocloud, for instance). This is decidedly not a post about the usefulness or future of SD-WAN solutions (though I do have opinions there, as you might have guessed). Rather, what I want to point out is that we, in the networking industry, tend to be rather sloppy about our language in ways that are not helpful.

To understand, it is useful to back up a few years and consider other technologies where our terms have become confused, and how it has impacted our ability to have effective discussions. When I first started in the networking world, there were gateways, there were routers, and there were switches. Gateways always looked at something beyond the destination IP address, and sometimes rewrote information in the packet, when forwarding or processing a packet. Routers always made a forwarding decisions based on the IP or network header, and modified the outer headers in the packet (the physical, or lower layer, headers). Specifically routers always perform a MAC header rewrite and decrement the Time to Live (TTL); switches never touched the packet, either the header or the contents.

There was, in the “old days,” another way in which routers and switches were different. Because routers must look deeper into the packet, and modify the packet, the original routing implementations could only be performed in software. Hence, for many years, routers processed packets in software, and switches processed packets in hardware.

When the original SSE was developed by Cisco, however, the marketing folks wanted emphasize the SSE could route in hardware. To convey this, they took the meaning of switching, that switching takes place in hardware, while routing takes place in software, and called these new deices layer 3 switches, Over time, of course, the layer 3 switch was reduced to just a switch, so now a switch is “anything that can process packets fast,” and routers are “anything that processes packets slow.”

The problem with this shift in terminology is that we no longer have a way to express the difference between a device that rewrites the MAC header and one that does not. A Top of Rack (ToR) switch in a data center may, in fact, perform a MAC header rewrite. So when someone says we should put a switch here, you have no idea if they mean a device that does MAC header rewrites or not. Routers are placed in the WAN, while switches are placed in the DC, even though they perform the same functions on the packet. Confusion ensues.

There is no way I can convince people to stop using router and switch interchangeably.

How does this relate to the article quoted above? What does MPLS mean? This is one of those terms that has two distinct meanings. It means, to at least some people, a widely used switching and tunneling technology. To others, however, it meas a particular kind of service—a layer 3 service running over an MPLS capable network operated as a service. The key point the article is making is that dedicated virtual circuits, provisioned and managed by a provider, are losing ground as a solution to SD-WAN solutions. Describing these services as MPLS uses one meaning of the term, but not the second.

The problem is, of course, that many people will read this sort of thing and say, “aha! Providers are getting rid of MPLS in their networks and replacing it with SD-WAN solutions.” This is simply a category error. It is a kind of service that is being replaced, not a technology.

The bottom line. This is nothing more than a call for consistent and clear terminology in the world of network engineering. I know we are fighting marketing machines that are looking for any sort of lever on which to stand, including “we use technology x, which makes our offering better.” This tendency, however, is bad for open and effective discussion in the network engineering community—and we should try to avoid it where we can.


  1. Jeff Tantsura on 28 June 2017 at 2:08 pm

    I have left similar comment – people (some deliberately, some due to lack of understanding) represent operational deficiencies as technological problem

  2. Michael Kashin on 1 July 2017 at 12:51 pm

    All these “X is dead” articles, where X can be MPLS, Openflow or CCIE, have one single goal – attract attention to a particular company’s product or service. The way to achieve that is by making the headline as controversial as possible as thus attract attention of a large group of people in the industry, whose knee-jerk reaction to such seemingly outrageous claims is to reply with a comment. Next, a clueless network engineer opens his/her social media page, sees this article with a large number of indignant replies from other engineers in his/her network, opens the article, reads it and learns that there’s a company called Aryaka, that provides “MPLS replacement solutions”. Mission accomplished.

    • Russ on 1 July 2017 at 10:14 pm

      I would agree — but i tend to think that we wouldn’t get trapped in this so easily if we separated the marketing hype from the reality a bit more often, and used words to mean what they really mean. Thanks for stopping by and commenting!



      • Deepak Arora on 4 July 2017 at 6:27 am

        I am pretty sure any Network Design Engineer who has ever done a MPLS Network design won’t fall into that trap 🙂

        Often I describe SDN as New Set of Tools to solve different business/technical problems, No matter how shiny those tools look like but we must understand the stuff under the hood and examine carefully before picking those up.

        The easiest example would be if someone doesn’t understand DMVPN and OSPF interaction or DMVPN and Multicast interaction from Design standpoint and challenges, most likely Vendor X’s SD-WAN is not going to deliver what Business was expecting from New Box in town.

        Evil CCIE