In the ever-evolving world of networking, debates often ignite innovative solutions. Recently, I encountered a provocative article titled "Traceroute isn’t real," which while amusing, misses the mark in a few areas. The name appears to reference the satirical "Birds Aren't Real" conspiracy theory, hinting that the article may be more satire than fact. Fortunately, astute commenters on platforms like Hacker News have taken on the task of dissecting the article's claims.

One of the most noteworthy assertions in that piece was the declaration that "it is completely impossible for MPLS to satisfy the expectations of traceroute." Having worked directly on MPLS (Multiprotocol Label Switching) at Cisco in the 1990s, I can confidently say this is incorrect. My involvement in the development of MPLS, particularly how we enabled traceroute functionality, remains vividly etched in my memory.

The Birth of MPLS: A Journey Back to 1996

I joined Cisco in 1995, empowered by the mission of integrating ATM (Asynchronous Transfer Mode) technologies into our IP-based products. By 1996, several engineers, including Yakov Rekhter, were brainstorming about new networking architectures when Yakov shared a revolutionary concept: Tag Switching. This idea quickly gained traction among us, leading to executive support for an architecture that would ultimately evolve into MPLS.

However, our journey was not without hiccups. At the same time, a rival startup named Ipsilon emerged with their own IP Switching solution, which looked quite different from what we were proposing. The buzz around Ipsilon greatly aided our efforts to garner enthusiasm for Tag Switching.

Interestingly, the core idea of associating fixed-length labels with variable-length IP prefixes was first presented by Girish Chandranmenon and George Varghese during SIGCOMM 1995. While Yakov's early work drew from these innovative concepts, neither document fully addressed the essential details of packet header encoding necessary for real-world implementation.

Challenges in Design and Implementation

As we worked on refining the Tag Switching specification, we knew we had a significant challenge ahead. We were about to introduce what I'd call a “label tax” — an additional header to carry fixed-length labels atop IP headers. Most of our customers, particularly ISPs, were keen on optimizing their bandwidth and often expressed disdain for ATM’s overhead, known as the "cell tax."

By minimizing the new label header's size, we aimed to balance functionality with efficiency. We needed significant fields, such as Class of Service and Time-to-Live (TTL), in our label header to ensure reliable, efficient packet forwarding. Our design committee made a critical yet challenging choice to include only a few bits of Class of Service due to the experimental nature of differentiated services at the time.

Embracing Traceroute in MPLS

Contrary to claims made elsewhere, we recognized traceroute as an invaluable network diagnostic tool. The design for performing traceroute over MPLS tunnels was straightforward: as a packet entered a tunnel, we copied the IP TTL value into the label header; each hop would decrement the outer TTL until the packet exited, when we’d copy it back. This ensured that traceroute functioned seamlessly over tunnels.

However, it came with a nuance no one could ignore — ISPs had reservations regarding traceroute's ability to reveal their internal network topology. By employing MPLS (or other tunneling technologies), providers could conceal their topology effectively.

We enabled a feature allowing providers to suppress ICMP time exceeded messages from internal routers, effectively masking network complexities. They could even adjust the TTL upon egress, allowing a tunnel to appear as just a single hop, regardless of actual routing depth. This capability, however, came with an internal jest about how to manage negative hop counts — a humorous yet impractical notion.

The Bigger Picture: Decisions Impacting the Network Landscape

Importantly, the decision not to support traceroute over tunnels stemmed from operator choices rather than an inherent flaw in MPLS. We aimed to ensure MPLS could coexist within diverse networks globally without significant backlash against its perceived inefficiencies.

In hindsight, while we didn’t achieve all our objectives flawlessly, the balance of trade-offs made between performance and functionality provided a framework that most stakeholders found agreeable. Our hard work paved the way for MPLS to become a cornerstone of modern networking, allowing extensive implementation across ISPs worldwide without inciting complaints about overhead.

Our journey taught us vital lessons about innovation, cooperation, and understanding customer needs in the fast-paced world of technology. The story of MPLS and traceroute is undoubtedly intertwined, showcasing the pivotal intersection of design, technology, and decision-making that continues to shape our networks today.