RFC 5704

RFC 5704 🎀 Uncoordinated Protocol Development Considered Harmful

Okay bestie, here's the deets 💖 This RFC is Informational, written by Stephen Bryant (S. Bryant, Ed.) and Monique Morrow (M. Morrow, Ed.) on behalf of the IAB 🧚 It was published in November 2009 and sits in the Network Working Group stream. The header doesn't list anything it obsoletes or updates, so it's a standalone vibe ✨

Abstract ✨

Okay so this doc is about the problems that can pop up when standards development organizations (SDOs) that share protocol interests don't coordinate or build things together 😬 Some of these problems could seriously harm the Internet 💀 The doc says we need a robust procedure to stop this from happening in the future 🔥 The IAB picked some case studies, like Transport MPLS (T-MPLS), to show how uncoordinated changes to a protocol can threaten the Internet's architecture 🍓

Here's the lowkey good news 🌈 Working through this stuff actually improved the relationship between the IETF and the ITU-T 👑 That happened through the "Joint working team on MPLS-TP", and the leaders of both orgs agreed to tighten up how they work together so ITU-T Recommendations and IETF RFCs don't clash later 🫶

Also, even though the examples are ITU-T and IETF, the scope covers every SDO with overlapping protocol interests with the IETF 🦋

Status of This Memo

This memo gives information to the Internet community 💜 It does not specify an Internet standard of any kind 🙈 Distribution of this memo is unlimited ✨

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 🎀

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document 📜 Please read these carefully, because they spell out your rights and restrictions for this document 💅 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the BSD License 🌸

Table of Contents

1. Introduction ....................................................2
2. Protocol Design Rules ...........................................3
   2.1. Protocol Safety ............................................3
   2.2. Importance of Invariants ...................................4
   2.3. Importance of Correct Identification .......................4
   2.4. The Role of the Design Authority ...........................4
   2.5. Ships in the Night .........................................5
3. Examples of Miscoordination .....................................6
   3.1. T-MPLS as a Case Study .....................................6
   3.2. PPP over SONET/SDH (Synchronous Optical Network /
        Synchronous Digital Hierarchy ..............................6
4. Managing Information Flow .......................................7
   4.1. Managing Information Flow within an SDO ....................7
   4.2. Managing Information Flow between SDOs .....................7
5. MPLS-TP as Best Practice ........................................7
6. IETF Change Process .............................................8
7. Security Considerations .........................................8
8. Acknowledgments .................................................8
9. IAB Members at the Time of This Writing .........................8
10. Emerging Issues ................................................9
11. Conclusion .....................................................9
12. Informative References .........................................9
Appendix A.  A Review of the T-MPLS Case ..........................12
  A.1.  Multiple Definitions of Label 14 ..........................12
  A.2.  Redefinition of TTL Semantics .............................13
  A.3.  Reservation of Additional Labels ..........................13
  A.4.  Redefinition of MPLS EXP Bits .............................14
  A.5.  The Consequences for the Network Operators ................14
  A.6.  The Consequences for the SDOs .............................15

1. Introduction 🦋

Okay so here's the setup 🌸 When an SDO uncoordinatedly adapts a protocol, a parameter, or a code-point, the risk of harm to the Internet goes way up 😭 This happens either when a code-point gets allocated without following the formal registration procedures, or when someone quietly changes the semantics of the protocol or what the code-point is meant to be used for [RFC4775] 💀

The point of this doc is to lay out the problems that can happen without formal coordination and joint development on protocols that SDOs have in common ✨ Some of those problems could seriously harm the Internet 🔥 The big idea is that the IAB sees it as an essential principle that only one SDO holds design authority for a given protocol 👑 That SDO gets the final say over allocating protocol parameter code-points, and over defining the intended semantics, interpretation, and actions tied to those code-points 💅

Right now there's a joint IETF - ITU-T effort called the MPLS Transport Profile (MPLS-TP) 🧚 It's moving fast to extend MPLS in a way that fits the MPLS architecture and fully meets the needs of the transport network provider [LS26] 🫶 As a case study, the doc looks at how the ITU-T protocol called Transport MPLS (T-MPLS) got designed and standardized 🍓 ITU-T Study Group 15 ended up abandoning T-MPLS [RFC5317] because it had inherent conflicts with the IETF's MPLS design, and especially with the Internet architecture 😬 Those conflicts came from a lack of coordination with the IETF, which is the design authority for MPLS 🙈

The goal here is to show why coordination matters for SDOs working together, and to explain a model for inter-SDO collaborative protocol development that the ITU-T and IETF are already using successfully 🎀

2. Protocol Design Rules 💜

This section covers a bunch of protocol design rules that keep a network running safely 🌈 Lots of protocol designers already know these, but they get restated here so everyone's assumptions are clear and consistent 🫶 Mismatched assumptions have been behind a lot of miscoordination and miscommunication between SDOs in the past 💀

2.1. Protocol Safety 🔥

Here's why the IAB and IETF treat uncoordinated use of code-points and/or protocol modification as a risk of harm to the Internet 🧠 We need to recap some key protocol design principles for big networks like the Internet ✨ Lots of end users and businesses depend on the Internet as part of their critical infrastructure, so large-scale networks carry huge economic value 💰 That means any outage caused by a protocol failure will lead to serious commercial and political damage 😭

When two incompatible protocols, or two forms of the same protocol, get deployed without coordination, there's a serious risk this could be catastrophic for the stability or security of the network 🚨

Also, the scale and distributed nature of the Internet can make it hard or even impossible to undo the long-term consequences of protocol incompatibility 🌀 So the following issues are of critical importance 👑

2.2. Importance of Invariants 🌸

Invariants are core properties that stay consistent across the network and don't change over extremely long time-scales 🦋 Protocol designers use them as axioms when they design protocols 🧚 A protocol often relies absolutely on an invariant to resolve a design corner case 💅 One example is an invariant that got inherited from IP into MPLS: a time to live (TTL) value gets monotonically decreased, and a packet with TTL<=1 will not be forwarded 🙈 That's a safety mechanism for reducing the damage from packet-forwarding loops 🔁 Another example is the way MPLS gives special semantics to the reserved label set 0..15 [RFC3032], plus the idea that a Label Switched Router (LSR) is free to allocate labels with a value of 16 or greater for its own use 🍓

2.3. Importance of Correct Identification 🎀

A code-point is a special kind of invariant, and it's used to identify a packet type or a component inside a packet ✨ Without these identifiers, a packet is just an opaque sequence of bits 🫥 A packet parser works by first identifying the code-point, then using the semantics tied to that code-point to interpret the other components in the packet 🧩 Once a code-point is defined, the interpretation of its associated data and the consequential actions become protocol invariants 🔒 Later protocol development has to stick to those invariants 💅 The semantics for an allocated code-point must never change 🚫 If a future enhancement needs different semantics, interpretation, or action, then a new code-point must be obtained 🦋

2.4. The Role of the Design Authority 👑

A code-point like an IEEE Ethertype gets allocated to a design authority, such as the IETF 🧚 That design authority is the one that establishes how information identified by the code-point should be interpreted, so the right invariants are associated with it 💜 Changing and extending a protocol takes great care 🥹 You need to really understand the exact nature of the invariants and what a modification will cause 🧠 That understanding isn't always possible when organizations modify protocols without the experience of the original designers or the design authority's expert pool 😬 And since there can only safely be a single interpretation of the information a code-point identifies, there must be a unique authority in charge of authorizing and documenting the semantics of that information and the consequential protocol actions 🔐

In the case of IP and MPLS technologies, the design authority is the IETF 🌈 The IETF has an internal process for evolving and maintaining the protocols it's the design authority for ✨ It also has change processes in place [RFC4929] to work with other SDOs that need enhancements to its protocols and architectures 🫶 Similarly, the ITU-T holds design authority for Recommendation E.164 [E.164] and allocates the relevant code-points 📞 Even so, the IETF is the design authority for the protocols ("ENUM") used to access E.164 numbers through the Internet DNS [RFC3245] 🍓

It's a recommendation of this document that the IETF introduces additional change mechanisms to cover all of the technical areas it has design authority for 🎀 Let's go!! 🌟

2.5. Ships in the Night 🚢

Okay so a designer might be tempted to say their protocol extensions are totally safe, even though they break the invariants of the original protocol, because the variants will just be ships in the night 🌙. Basically, these variants will never exist in the same network domain at the same time and will never need to inter-work. Bestie, this is a fundamentally unsound assumption, and ngl it fails for a bunch of reasons. First, it is infeasible to ensure the two instances will never be interconnected under any circumstances 💀. Second, even if the operators deploying the protocols do their due diligence so the two instances don't conflict, it is infeasible to ensure that conflicting protocols won't get interconnected under fault conditions. Literally out of anyone's control 😭.

This ships-in-the-night vibe is extra hazardous when the instances share the same identifying code-point 🚨. The reason is that a system can't tell which variant of the protocol it received, so it can't correctly interpret the associated information, and it can't figure out which protocol actions are safe to execute. That's a whole mess 🙃.

---

3. Examples of Miscoordination 🔍

There are a bunch of examples where a lack of inter-SDO coordination led to flawed protocol designs getting published 🥲. This section walks through a few case studies that show the coordination problems.

3.1. T-MPLS as a Case Study 💜

A recent example of another SDO creating a protocol based on misunderstandings of IETF protocols is T-MPLS. T-MPLS was created in ITU-T in an attempt to design a packet-transport method for transport-oriented networks. This is actually a success story for IETF protocols, and ITU-T's interest in and selection of MPLS is a compliment to the IETF work 🎀. Quite late in the ITU-T design and specification cycle, there were a number of liaison exchanges between ITU-T and the IETF, where the IETF became increasingly concerned about incompatibility of IETF MPLS procedures and technologies with ITU-T T-MPLS [RFC5317]. There were extensive discussions about interpretation, definition, and misunderstandings around things like MPLS Label 14, MPLS swap operation, TTL semantics, reservation of additional labels, and EXP bits 🤯. If ITU-T had worked with the IETF from the start, these problems could have been avoided. A detailed analysis of the T-MPLS case is in Appendix A.

3.2. PPP over SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) 🌈

An example of the IETF failing to coordinate with ITU-T is [RFC1619], which defined PPP over SONET. In the text dealing with the SONET/SDH Synchronous Payload Envelope (SPE), the document erroneously stated that "no scrambling is needed during insertion into the SPE." Later, SONET experts working in ITU-T and in ANSI figured out that this error came from an incomplete understanding of the SONET scrambler 🧐. Because there was no scrambler, the protocol was trying to transport non-transparent data over SONET. The result was lost or misinterpreted data in the Packet over SONET (PoS) network, which hit routing, signaling, and end-user data traffic. The details are described in [PPPoSONET]. This problem would have been prevented if the IETF had worked with ITU-T and ANSI when it was initially developing [RFC1619]. It got fixed by working jointly with ITU-T and ANSI experts to publish [RFC2615], which mandated the use of scrambling ✨.

Note that [RFC1619] was developed four years before the IETF and ITU-T agreed on formal procedures for cooperation, as documented in [RFC2436] (which was later obsoleted by [RFC3356]). Timing is everything, babe ⏰.

4. Managing Information Flow 📬

This section recommends that intra- and inter-SDO information flows get careful management 💅. The goal is to prevent protocols from being accidentally extended without full coordination with the relevant design authority.

4.1. Managing Information Flow within an SDO 🏠

You can't assume an SDO is completely familiar with the internal structure, information exchange, or internal processes of another SDO. So the initial contact point, and the subgroup that forms a long-term working relationship, has a duty to make sure the work is fully notified and coordinated to all relevant parties within the SDO 🫶.

4.2. Managing Information Flow between SDOs 🤝

Here's the recommendation: as part of their document-approval process, SDOs should confirm that all protocol parameters, code-points, TLV identifiers, etc., have been authorized by the appropriate design authority (e.g., IANA, IETF, etc. in this case). They should also confirm that SDO approval from the design authority was obtained before protocol extensions get published. This confirmation should be an integral part of the approval or consent process, since it's how you verify that the normative references are qualified ✅.

5. MPLS-TP as Best Practice 🏆

To bridge the gap between the two organizations, the IETF and ITU-T set up a joint working team (JWT). Its job was to assess whether it was possible to enhance existing MPLS standards into a best-in-class solution for transport networks 🛤️. The outcome of that investigation is reported in [RFC5317].

The JWT proposed a design that was acceptable to both SDOs, and that led to the creation of the MPLS-TP project. It's a joint project where ITU-T experts work with the IETF on protocol-development tasks, while IETF members work within ITU-T to understand requirements and help create ITU-T recommendations describing MPLS-TP. The technical definition comes through normative references to IETF RFCs, which is so cute 🥹.

Although the JWT approach let the IETF and ITU-T agree on a way to resolve the T-MPLS problem, it cost a lot of resources 💸. The JWT needed considerable protocol-design expertise and IETF management time to agree on a suitable technical solution. A lightweight process, starting with close coordination during the requirements phase and continuing through the development phase, would likely bring the resources needed down to an acceptable level in the future 🌸.

6. IETF Change Process 🔄

There is an MPLS-change-process [RFC4929]. However, the IETF has not yet defined a change process that applies to all of its work areas. The problems described in this document show that the IETF needs to develop a universal change process 👑. The MPLS-change-process would seem to be a suitable starting point.

7. Security Considerations 🚨

The uncoordinated development of protocols poses a risk of harm to the Internet and must not be permitted. Full stop, no exceptions 💀.

The enhancement or modification of a protocol can increase attack surfaces considerably, and that may compromise the security or stability of the Internet 😱. The IETF has a review process that combines cross-area review with specialist security review by experts who know the development and deployment context of the Internet protocol suite. Because the Internet infrastructure relies so heavily on the IP and MPLS protocol suites, this security review process must be exercised with considerable diligence 🔐. Failing to apply this review process exposes the Internet to increased risk along both security and stability vectors. Not a risk worth taking 🙅‍♀️.

8. Acknowledgments 💌

The authors wish to acknowledge Loa Andersson for his contribution to this work 🧚.

9. IAB Members at the Time of This Writing 🌟

• Marcelo Bagnulo
• Gonzalo Camarillo
• Stuart Cheshire
• Vijay Gill
• Russ Housley
• John Klensin
• Olaf Kolkman
• Gregory Lebovitz
• Andrew Malis
• Danny McPherson
• David Oran
• Jon Peterson
• Dave Thaler

10. Emerging Issues 👀

Even though we used T-MPLS as a case study, there are other ongoing ITU-T projects and core IETF specifications that could be the subject of better coordination or new conflicts 🔮. Which one happens depends on whether the IETF and ITU adhere to the principles outlined in this document. Two current examples are [Y.2015] and [Q.Flowsig]. New areas with potential for cooperation or conflict are emerging from the work of ITU-T SG13 Question 7, "IPv6" -- for example: [Y.ipv6split] and [Y.ipv6migration].

Improved coordination, of course, isn't limited to the IETF and ITU-T relationship. This issue shows up between a whole set of SDOs. The IETF and ITU-T relationship just happens to be the example we used, because there's a recent case where a potential disaster was, thanks to a lot of hard work, not only prevented but turned into a net gain for everyone 🥳.

11. Conclusion 🎀

It's important that all SDOs developing standards that affect the operation of the Internet learn the lessons from the cases cited in this document 📚. Uncoordinated parallel work between SDOs creates serious problems, with potentially damaging operational impact on those who deploy and use the Internet 💥. Both inter- and intra-SDO information flow needs to be well managed, so that all impacted parties are aware of work items. Finally, the IETF needs to develop a universal change process that covers all of its work areas, no cap 🫶🌈.

12. Informative References ✨

[E.164]       ITU-T, "ITU Recommendation E.164: The international
              public telecommunication numbering plan",
              February 2005.

[LS26]        ITU-T Study Group 15, "Cooperation Between IETF and
              ITU-T on the Development of MPLS-TP", Geneva,
              December 2008, <https://datatracker.ietf.org/
              documents/LIAISON/file596.pdf>.

[PPPoSONET]   Manchester, J., et al., "PPP over SONET/SDH", Work in
              Progress, October 1997.

[Q.Flowsig]   ITU-T Study Group 11, Question 5, "Signalling protocols
              and procedures relating to flow state aware access QoS
              control in an NGN", Draft Recommendation.

[RFC1393]     Malkin, G., "Traceroute Using an IP Option", RFC 1393,
              January 1993.

[RFC1619]     Simpson, W., "PPP over SONET/SDH", RFC 1619, May 1994.

[RFC2436]     Brett, R., Bradner, S., and G. Parsons, "Collaboration
              between ISOC/IETF and ITU-T", RFC 2436, October 1998.

[RFC2615]     Malis, A. and W. Simpson, "PPP over SONET/SDH",
              RFC 2615, June 1999.

[RFC3031]     Rosen, E., Viswanathan, A., and R. Callon,
              "Multiprotocol Label Switching Architecture", RFC 3031,
              January 2001.

[RFC3032]     Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

[RFC3245]     Klensin, J. and IAB, "The History and Context of
              Telephone Number Mapping (ENUM) Operational Decisions:
              Informational Documents Contributed to ITU-T Study
              Group 2 (SG2)", RFC 3245, March 2002.

[RFC3270]     Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
              Vaananen, P., Krishnan, R., Cheval, P., and J.
              Heinanen, "Multi-Protocol Label Switching (MPLS)
              Support of Differentiated Services", RFC 3270,
              May 2002.

[RFC3356]     Fishman, G. and S. Bradner, "Internet Engineering Task
              Force and International Telecommunication Union -
              Telecommunications Standardization Sector Collaboration
              Guidelines", RFC 3356, August 2002.

[RFC3429]     Ohta, H., "Assignment of the 'OAM Alert Label' for
              Multiprotocol Label Switching Architecture (MPLS)
              Operation and Maintenance (OAM) Functions", RFC 3429,
              November 2002.

[RFC4379]     Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

[RFC4775]     Bradner, S., Carpenter, B., and T. Narten, "Procedures
              for Protocol Extensions and Variations", BCP 125,
              RFC 4775, December 2006.

[RFC4929]     Andersson, L. and A. Farrel, "Change Process for
              Multiprotocol Label Switching (MPLS) and Generalized
              MPLS (GMPLS) Protocols and Procedures", BCP 129,
              RFC 4929, June 2007.

[RFC5129]     Davie, B., Briscoe, B., and J. Tay, "Explicit
              Congestion Marking in MPLS", RFC 5129, January 2008.

[RFC5317]     Bryant, S. and L. Andersson, "Joint Working Team (JWT)
              Report on MPLS Architectural Considerations for a
              Transport Profile", RFC 5317, February 2009.

[RFC5462]     Andersson, L. and R. Asati, "Multiprotocol Label
              Switching (MPLS) Label Stack Entry: "EXP" Field Renamed
              to "Traffic Class" Field", RFC 5462, February 2009.

[RFC5654]     Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher,
              N., and S. Ueno, "Requirements of an MPLS Transport
              Profile", RFC 5654, September 2009.

[Y.1711-2002] ITU-T Study Group 13, "ITU-T Recommendation Y.1711: OAM
              mechanism for MPLS networks", November 2002.

[Y.1711-2004] ITU-T Study Group 13, "ITU-T Recommendation Y.1711: OAM
              mechanism for MPLS networks", February 2004.

[Y.1711am1]   ITU-T Study Group 13, "ITU-T Recommendation Y.1711
              Amendment 1: New Function Type Codes", October 2005.

[Y.1711cor1]  ITU-T Study Group 13, "ITU-T Recommendation Y.1711
              (2004) corrigendum 1", February 2005.

[Y.2015]      ITU-T Study Group 13, Question 5, "General Requirements
              for ID/Locator Separation in NGN".

[Y.ipv6migration]
              ITU-T, "ITU draft Y.ipv6migration: Roadmap for IPv6
              migration from NGN operators perspective", 2009.

[Y.ipv6split] ITU-T, "ITU draft Y.ipv6split: Framework of ID/LOC
              separation in IPv6-based NGN", 2009.

Appendix A. A Review of the T-MPLS Case 🔍💖

Okay so, T-MPLS was created in ITU-T as an attempt to design an MPLS-based packet-transport method for transport-oriented networks 🦋. This appendix walks through the technical issues the IETF spotted in the T-MPLS documents and what those issues would have caused. Let's get into the tea 🫖☕

A.1. Multiple Definitions of Label 14

To get why using MPLS Reserved Label 14 for T-MPLS was a safety concern for the Internet, you first need to know which current standards already use it 🎀

The governing standard on the use of MPLS Reserved Label 14 is [RFC3429], "Assignment of the 'OAM Alert Label' for Multiprotocol Label Switching Architecture (MPLS) Operation and Maintenance (OAM) Functions" 📜

Label 14 belongs to one specific protocol: ITU-T Recommendation [Y.1711-2002] 🌸

That 2002 Recommendation has since been superseded by newer versions, namely [Y.1711-2004], [Y.1711cor1], and [Y.1711am1]. Not gonna lie, that's a lot of versions 💀 All three are still in force as ITU-T Recommendations, though, so they're all very much alive ✨

Here's the problem 😭. The changes made to Y.1711 never got reflected in an update to RFC 3429, which only defines the protocol as specified by the now superseded 2002 Recommendation. So, for example, MPLS equipment responding to an MPLS packet containing Label 14 would expect to see the 2002 version of the Y.1711 [Y.1711-2002] protocol, and would not recognize any of the new function codes specified in Y.1711 Amendment 1. This happens because Y.1711 has no version field, and RFC 3429 doesn't offer any other way to tell apart non-interoperable versions of Y.1711. Having a version number in the protocol would let an implementer codify non-interoperability, which is the opposite of what we want 🙅‍♀️. And honestly, the IETF is the authority over Label 14 semantics, so it has the final say over keeping the protocol that uses this code-point interoperable, unless the IETF explicitly hands that authority off to someone else 👑

With regard to T-MPLS, the ITU-T and the IETF weren't coordinating well on redefining what MPLS Label 14 means. That gap ended up producing protocol definitions that clashed with the IETF MPLS architecture 💅

Now, the MPLS architecture [RFC3031] defines a swap operation as an atomic function that replaces the top label in an MPLS label stack with another label, which gives context for the next hop LSR 🧚. But the ITU-T Recommendations that specified the new OAM functions defined by Label 14 redefined the label-swap operation as a POP, followed by a PUSH. That means every LSR would have to inspect the label stack for Label 14 at each hop 😱. This proposed new behaviour conflicts with the IETF definition of a swap operation, full stop.

This is a big deal. The behaviour proposed in these specifications would have had major consequences for deployed hardware designs. Equipment built to the two different specifications would have ended up incompatible with each other 🚨. That's exactly why the atomic procedure defined in [RFC3031] needs to stay unchanged 🫶

A.2. Redefinition of TTL Semantics

The standard way to deliver an OAM message to an entity on a Label Switched Path (LSP), so that the OAM message shares its fate with the data traffic, is to use TTL expiry ⏳. The IETF's Internet Protocol (IP) uses this mechanism for traceroute [RFC1393], and MPLS ping [RFC4379] does too 🔥

At one stage, the T-MPLS designers considered a multi-level OAM design. In that design, the OAM packet got steered to its target by a process where some nodes increased the TTL as they forwarded the OAM packet to its next hop 😬. But TTL is a safety device in the IETF IP and MPLS architecture. It stops a packet from looping forever when something goes wrong 🌀. So the proposed extension for an enhanced OAM mechanism broke an MPLS design invariant that was specifically put in place to keep the Internet safe by preventing persistent forwarding loops. Big no-no 🙅‍♀️

A.3. Reservation of Additional Labels

The IETF MPLS protocol uses a small number of reserved labels [RFC3032] to add context and to trigger some special processing operations in the forwarder 🎀. All other labels used for forwarding get their semantics from the forwarding equivalence class (FEC) 🦋.

In an early implementation of T-MPLS, the designers decided they needed some extra labels to alert the forwarder that a packet needed special processing. That created a conflict between the behaviour of an IETF MPLS LSR and the LSRs operating under the ITU-T Recommendation 💔. So some LSRs would attribute special semantics to Labels 16..31, whilst other LSRs would just perform normal forwarding on them. Chaos, honestly 🌪️

A.4. Redefinition of MPLS EXP Bits

The early MPLS documents defined the form of the MPLS label stack entry [RFC3032]. That includes a three-bit field called the "EXP field" 🍓. Those documents didn't define its exact use, except to say it was "reserved for experimental use" 🧪.

The intended use of the EXP field was as a "Class of Service" (CoS) field. But the early documents didn't name it a CoS field, because they didn't think that use was defined well enough yet 🤷‍♀️. Fast forward, and a number of standards documents now define its usage as a CoS field ([RFC3270], [RFC5129]), and hardware is out there deployed that assumes this exclusive usage 🏗️.

The T-MPLS designers didn't know about the historic reason for the "provisional" naming of this field. They assumed the bits were free for any experimental use, so they repurposed them to indicate the maintenance-entity level (a hierarchical maintenance mechanism) 😭. Oops.

The intended use of the EXP field was eventually carried forward in [RFC5462], which formally changed the name to Traffic Class (TC). That reinforces the usage and makes it official, so the bits are now officially spoken for 💜✨

A.5. The Consequences for the Network Operators 💼✨

Okay so transport network operators want the statistical gain you get from packet networking, but they also want to keep the familiar structure of their SONET/SDH networks 🦋. That's the whole goal. T-MPLS was an attempt to deliver it. The problem is that building an incompatible variant of MPLS without tight coordination with the IETF created a bunch of headaches for operators 😭.

First, operators who deployed T-MPLS in production networks now have to deal with the risk and complexity of moving their networks over to MPLS-TP. Second, there was a knock-on delay in the enhancements MPLS needed to meet their needs [RFC5654], because the IETF and ITU-T had to redevelop MPLS-based transport network protocols 🌀.

Thankfully, the two organizations are now working together to design the necessary enhancements 🫶

The resulting technology, MPLS-TP, brings big benefits to everyone 🎀. But it didn't come free. Honestly, we can't be sure what would have happened if things had kept going the way they were. At the very least, the wider MPLS community would have missed out on better OAM, and the transport community would have missed out on the many perks of an interoperable solution 💔.

A.6. The Consequences for the SDOs 🏛️

Resolving all this took a huge amount of resources and caused a lot of conflict between the IETF and the ITU-T 😬. Much of that conflict played out in public, and it hurt both organizations. The worst part is that the conflict-resolution process ate up the very resources needed to build an optimal architecture for MPLS in transport networks 💀.

---

Authors' Addresses 💌

Stewart Bryant (editor)

EMail: stbryant@cisco.com

Monique Morrow (editor)

EMail: mmorrow@cisco.com

Internet Architecture Board

EMail: iab@iab.org