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.