ScopeScope

MPLS = Multi-Protocol Label Switching That’s a good description of the data plane However, the control plane is equally important

MPLS (as used here) will cover new protocols and extensions of existing protocols from the MPLS, CCAMP, {L1, L2, L3} VPN, and PWE3 WGs There is work in other WGs that has also had a

fairly big influence on MPLS’s development

Initial Goals of MPLSInitial Goals of MPLS

Enable faster forwarding of IPv4 traffic

Bring explicit routing to IP networks

Allow effective “traffic engineering” in IP networks

Facilitate integration of routers and ATM switches

Allow hierarchy of routing knowledge (aka “BGP-free core”)

Drivers for DeploymentDrivers for Deployment

1998: RFC 2547 VPNs 1999: Traffic Engineering and Fast Reroute 2001+: Network convergence

First, using Frame Relay & ATM emulation over MPLS Later, point-to-point Ethernet emulation over MPLS

2003: VPLS (multipoint Ethernet over MPLS) 2005+: metro backhaul – DSL, and later mobile

traffic Also, BGP-free core (not a driver, rather a fallout)

2006: Video distribution (driver for p2mp LSPs)

ArchitectureArchitecture

MPLS architecture is a study in pragmatism Approach is quite different from other SDOs

RFC 3031 (MPLS Architecture) talks fairly specifically about forwarding, label distribution and hierarchy The authors had a fairly clear picture in mind of what

these mean and how they should be implemented

It also talks about Penultimate Hop Popping (PHP)

But it doesn’t talk about “payload identification”

Architectural Failures?Architectural Failures?

PHP is often touted as a failure of the MPLS architecture, whereas it is just a clever hack, and not a fundamental aspect of the architecture PHP is a local decision of each device in the network

OTOH, the lack of a payload ID is fairly ingrained Changing this would have large ramifications to

hardware implementations and thus to the installed base

Then again, changing this may not buy much (see later)

Protocols SpecsProtocols Specs

MPLS protocol development was also very pragmatic Only two new protocols were defined: LDP and LMP The rest was done by extending existing protocols …

… even if they weren’t “designed” to do such things

MPLS protocol specs have lots of wiggle room both in terms of looseness of the specs, and in the

ability to define new extensions The wide disparity between the original expected

utility of MPLS and the actual reasons for deployment underscores the value of this flexibility

Protocol SpecsProtocol Specs

The lack of tight constraints on the FECs that define labels in a label stack gives MPLS a lot of power Label stacking enables VPNs, hierarchy, FRR, etc.;

and the easy concatenation of several features It was once thought that two labels would be plenty Now, we have applications for 5 or more labels

Consider the notion of a “hash label” – a label in the label stack that is not used for forwarding, but whose only purpose is to improve load balancing BTW, this eliminates the main reason for a payload ID

Competing SpecsCompeting Specs

It also seems that MPLS specs came in competing pairs RSVP-TE vs. CR-LDP RFC 2547/4364 VPNs vs. Virtual Routers Fast Reroute via “Detours” vs. “Facility backup” BGP vs. LDP for L2VPNs and VPLS LMP (RFC 4204) vs. NTIP P2MP RSVP-TE LSPs: “sub-LSPs” vs. “trees” Multicast in 2547 VPNs

Competing SpecsCompeting Specs

Competing SpecsCompeting Specs

In many cases, competition has pushed one or the other standard to do more: CR-LDP pushed RSVP-TE to “firm state” BGP pushed LDP L2VPNs and VPLS to “BGP-

based auto-discovery” P2MP RSVP-TE: “trees” pushed “sub-LSPs” to

more compact representations

Protocol Protocol ImplementationImplementation

Especially early on, implementation was often concurrent with specification Real deployment was often prior to

standardization

This meant: A fair amount of inter-vendor communication A fair amount of reverse engineering A few knobs for “alternate” behaviors :-)

Protocol Protocol ImplementationImplementation

As the 70 lb chimp in this game, my company very often had to implement both of competing standards This meant quite a bit of duplicated work At the same time, this gave us a unique insight into

the pros and cons of each of the competing standards

On balance, we prefer competing standards to a King Solomon approach To a large degree, because of our collective inability to

accurately predict the future

Protocol ProtectionProtocol Protection

MPLS and GMPLS were also extremely popular … so much so that other SDOs wanted to “help”

extend IETF protocols

In retrospect, the IETF could have done more to protect protocols Clearly demarcating “standards track” extensions

from other types, and requiring appropriate due process

Proactively sending liaisons or other communication to SDOs that begin work on IETF standards

SummarySummary

A pragmatic approach to architecture and protocol design is key to “success” This means implementation concurrent with specs

A single standard appears the right approach But often, having competing standards is better,

even if this means more work all around

Extensibility is another key factor for success If you think you have a good crystal ball, use it to

play the market, not for protocol design :-)