queuefull blog

For a while now I’ve been hearing about a “war” between MPLS and Carrier Ethernet proponents. Sometimes it’s framed as an IETF versus IEEE debate. Sometimes it’s framed as the incumbent carriers versus next-generation service providers. And so on. Take for instance a blog post by Nortel’s CTO, John Roese, discussing The Future of the Internet Core. Essentially he is hyping PBT by pitting it against MPLS. But I don’t buy it. This isn’t about technology, it’s just marketing propaganda.

Today, vendors of MPLS gear such as Cisco and Juniper have solid footing in an established market. They created the technology, hyped it, built products and captured a market. Subsequently, other players such as Alcatel-Lucent (via Alcatel’s acquisition of TiMetra) and Tellabs (via their acquisition of Vivace) have been moderately successful at capturing market share by building platforms with relatively more software stability, interface flexibility, etc. But other vendors like Nortel just don’t have the credibility, have failed to produce a product of compelling value (15k? Neptune?), and as a result have failed to penetrate the market.

So, unable to penetrate the existing MPLS market Nortel has instead created a new market which they can own. They call the technology Provider Backbone Bridging (PBB, PBT, etc), and it has real value. Fundamentally PBB is MAC-in-MAC encapsulation, which pushes customer MAC forwarding tables to the edge nodes and allows the core to scale up. They’ve also defined protection schemes and OAM functionality, which makes Ethernet more suitable as a medium for critical transmission paths (i.e. to replace POS connections between core routers).

However PBB-TE relies on an end-to-end external management system, which is a paradigm that doesn’t fit too well with service creation in today’s dynamic packet networks. Frankly, those of us involved in operational network architecture were happy to move from ATM/FR to MPLS for Traffic Engineering. This is in large part because MPLS provides a set of tools that let the operator get away from static definition of paths, hop-by-hop configuration, and external management systems. On the other hand this is exactly what we want in metro environments for creating customer site connectivity, or perhaps even in the long-haul optical network as a Layer-1 path management mechanism.

Further, and more importantly, today’s MPLS-based platforms not only provide TE but also provide services. For instance L3VPN, aka BGP/MPLS Layer-3 VPN, is a popular application of MPLS. Similarly, MPLS enables L2VPN services such as VPLS. These services can even be provided side by side, on the same platforms that provide Internet access, IPTV, and so on. And they can be managed using the same mechanisms that have helped operators manage IP networks for decades.

So what is the battle about? Both technologies have their pros and cons, and seem to compliment each other. For instance I might use the OAM features of PBB in my long-haul transmission network, to carry MPLS traffic between core routers. I might use MPLS in my core network to create services, perform packet-layer traffic engineering, and enable operational monitoring. And I might use PBB in metro environments to connect customer sites into my provider edge router platform.

Personally I think the “battle” is a way for PBB vendors to get attention. The trade magazines and analysts love a good fight, and both Ethernet and MPLS are widely used (and hyped) technologies. Nortel has been fairly shrewd to leverage this situation into market awareness. But really, come on, it’s about time to move along. PBB and MPLS technologies are both going to be a part of networks going forward, along with ATM/FR and all the other legacy technology that has contributed (evolved) to the current state of the art.

If you really want an interesting topic, let’s start talking about TRILL. (Can you imagine it? PBB in the metro network, VPLS over MPLS in the core network, and TRILL in the Datacenter…)