2. Scope  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

3. Initial Goals of MPLS EEnable faster forwarding of IPv4 traffic BBring explicit routing to IP networks AAllow effective “traffic engineering” in IP networks FFacilitate integration of routers and ATM switches AAllow hierarchy of routing knowledge ((aka “BGP-free core”)

4. Drivers 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)

5. Architecture  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”

6. 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)

7. Protocols 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

8. Protocol 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

9. Competing 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

10. Competing Specs  Some of these died  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

11. Competing 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

12. Protocol Implementation  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 :-)

13. Protocol Implementation  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

14. Protocol 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

15. Summary  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 :-)