RFC 7274

Allocating and Retiring Special-Purpose MPLS Labels 🎀

Okay so this is RFC 7274 💅 It's an IETF Request for Comments (the official Internet standards doc, the vibes are very "the rules, but make it Standards Track") and it's written by K. Kompella from Juniper Networks, L. Andersson from Huawei, and A. Farrel from Juniper Networks. It's a Standards Track document, published in June 2014, with ISSN 2070-1721. It updates RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478 and 6790 🦋 It doesn't list anything it obsoletes.

Abstract ✨

Some MPLS labels have been given specific jobs already 🧚 There's a block of labels (0-15) set aside for this, and they're usually called "reserved labels". This doc calls them "special-purpose labels" instead.

Since there are only 16 of these special-purpose labels, you have to be careful when you allocate a new one 🫶 But at the same time, you shouldn't block progress when a new one is genuinely needed.

This memo defines new procedures for allocating and retiring special-purpose labels 🌈 It also adds a way to extend the special-purpose label space and explains how to handle extended special-purpose labels in the data plane. Last but not least, it renames the IANA registry for special-purpose labels to "Special-Purpose MPLS Label Values" and creates a brand new registry called the "Extended Special-Purpose MPLS Label Values" registry.

This document updates a bunch of older RFCs that use the term "reserved label", namely RFCs 3032, 3038, 3209, 3811, 4182, 4928, 5331, 5586, 5921, 5960, 6391, 6478, and 6790 💜

Status of This Memo ⭐

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it's had public review, and the Internet Engineering Steering Group (IESG) approved it for publication. You can find more about Internet Standards in Section 2 of RFC 5741.

For the current status of this document, any errata, and how to send feedback on it, check out http://www.rfc-editor.org/info/rfc7274.

Copyright Notice 🔥

Copyright (c) 2014 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) as in effect on the date this document was published. Please actually read these documents, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License.

Table of Contents 🍓

   1. Introduction ....................................................3
      1.1. Conventions Used in This Document ..........................3
   2. Questions .......................................................3
   3. Answers .........................................................4
      3.1. Extended Special-Purpose MPLS Label Values .................5
      3.2. Process for Retiring Special-Purpose Labels ................6
   4. Updated RFCs ....................................................7
   5. IANA Considerations .............................................8
   6. Security Considerations .........................................8
   7. Acknowledgments .................................................9
   8. References ......................................................9
      8.1. Normative References .......................................9
      8.2. Informative References ....................................10

1. Introduction 🦋

Okay so the MPLS Label Stack Encoding spec [RFC3032] defined four special-purpose label values (0 to 3) and set aside values 4 through 15 for future use 🌸 These labels have special significance in both the control plane and the data plane. Since then, three more values have been allocated (values 7, 13, and 14 in [RFC6790], [RFC5586], and [RFC3429], respectively), which leaves nine unassigned values from the original space of sixteen.

Allocating three out of the remaining twelve special-purpose label values in about 12 years isn't a cause for concern in itself 🙈 The scarcity is the real problem. Plus, a lot of special-purpose labels need special processing by forwarding hardware, and changing that hardware is often expensive and sometimes impossible. So documenting a newly allocated special-purpose label value is super important, literally.

This memo walks through some of the issues with allocating and retiring special-purpose label values and defines mechanisms to deal with them 💅 It also extends the space of special-purpose labels.

1.1. Conventions Used in This Document 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Two new acronyms show up here:

• XL: Extension Label. A label that indicates that an extended special-purpose label follows.
• ESPL: Extended Special-Purpose Label. A special-purpose label that is placed in the label stack after the Extension Label. The combination of XL and ESPL might be regarded as a new form of "compound label" comprising more than one consecutive entry in the label stack. 🫧

2. Questions 🤔

In re-appraising MPLS special-purpose labels, these questions come to mind:

1. What allocation policies should be applied by IANA for the allocation of special-purpose labels? Should Early Allocation [RFC7120] be allowed? Should there be labels for experimental use or private use [RFC5226]?
2. What documentation is required for special-purpose labels allocated henceforth?
3. Should a special-purpose label ever be retired? What criteria are relevant here? Can a retired special-purpose label ever be re-allocated for a different purpose? What procedures and time frames are appropriate?
4. The special-purpose label value of 3 (the "Implicit NULL Label" [RFC3032]) is only used in signaling, never in the data plane. Could it (and should it) be used in the data plane? If so, how and for what purpose?
5. What is a feasible mechanism to extend the space of special-purpose labels should this become necessary?
6. Should extended special-purpose labels be used for load balancing?

3. Answers 💖

This section gives answers to the questions posed in the previous section, so let's get into it.

1. • A. Allocation of special-purpose MPLS labels is via "Standards Action".
   • B. The IANA registry will be renamed "Special-Purpose MPLS Label Values".
   • C. Early allocation may be allowed on a case-by-case basis.
   • D. The current space of 16 special-purpose labels is too small for setting aside values for experimental or private use. However, the "Extended Special-Purpose MPLS Label Values" registry created by this document has enough space, and this document defines a range for experimental use.
2. A Standards Track RFC must accompany a request for allocation of Standards Action special-purpose labels, as per [RFC5226].
3. The retirement of a special-purpose MPLS label value must follow a strict and well-documented process. This is necessary since we must avoid orphaning the use of this label value in existing deployments. This process is detailed in Section 3.2.
4. For now, the use of the "Implicit NULL Label" (value 3) in the data plane will not be allowed. If this decision is revisited later, an accompanying Standards Track RFC that details the use of the label, a discussion of possible sources of confusion between signaling and data plane, and mitigation thereof shall be required.
5. A special-purpose label (the "Extension Label", XL, value 15) is set aside for the purpose of extending the space of special-purpose labels. Further details are described in Section 3.1.
6. [RFC6790] says that special-purpose labels MUST NOT be used for load balancing. The same logic applies to extended special-purpose labels (ESPLs). Thus, this document specifies that ESPLs MUST NOT be used for load balancing. It is noted that existing implementations would violate this, as they do not recognize XL as anything other than a single special-purpose label and will not expect an ESPL to follow. The consequence is that if ESPLs are used in some packets of a flow, these packets may be delivered on different paths and so could be re-ordered. However, it is important to specify the correct behavior for future implementations, hence the use of "MUST NOT". 🔥

A further question that needed to be settled was whether a "regular" special-purpose label keeps its meaning if it follows the XL. The answer is in Section 3.1, so keep reading bestie 👑

3.1. Extended Special-Purpose MPLS Label Values 🧚

The XL MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an ESPL and interpreted as defined in a new registry created by this document (see Section 5). Whether or not L has the bottom-of-stack bit set depends on whether other labels follow L. The XL only assigns special meaning to L. A label after L (if any) is parsed as usual and thus may be a regular label or a special-purpose label; if the latter, it may be the XL and thus followed by another ESPL.

The label value 15 is set aside as the XL, as shown in Section 5.

Values 0-15 of the "Extended Special-Purpose MPLS Label Values" registry are set aside as reserved. Furthermore, values 0-6 and 8-15 MUST NOT appear in the data plane following an XL; an LSR processing a packet with an XL at the top of the label stack followed by a label with value 0-6 or 8-15 MUST drop the packet.

Label 7 (when received) retains its meaning as Entropy Label Indicator (ELI) whether it's a regular special-purpose label or an ESPL. This is because of backwards compatibility with existing implemented and deployed code and hardware that looks for the ELI without verifying if the previous label is XL or not. However, when an LSR inserts an entropy label, it MUST insert the ELI as a regular special-purpose label, not as an ESPL. 🌸

3.1.1. Forwarding Packets with Extended Special-Purpose Labels 🫶

If an LSR encounters the XL at the top of the stack and it doesn't understand extension labels, it MUST drop the packet as specified for the handling of an invalid incoming label according to [RFC3031]. If an LSR encounters an ESPL at the top of the stack (after the XL) that it does not understand, it MUST drop the packet, again following the same procedure. In either case, the LSR MAY log the event, but such logging MUST be rate-limited. 🙈

An LSR SHOULD NOT make forwarding decisions on labels that aren't at the top of the stack. For load-balancing decisions, see Answer 6 in Section 3.

3.1.2. Choosing a New Special-Purpose Label

okay so when you're allocating a brand new special-purpose label, protocol designers should consider whether they could use an extended special-purpose label instead 🦋 bestie, this is giving resource preservation energy ✨ the whole point is to protect the scarce "normal" special-purpose labels for the situations where keeping the label stack small really matters 💅

3.2. Process for Retiring Special-Purpose Labels

ngl this part is so serious 😭 the process is defined "for the sake of completeness," but retiring special-purpose labels is genuinely difficult, so it is recommended that this process be used sparingly 🫶

a. A label value that has been assigned from the "Special-Purpose MPLS Label Values" registry may be deprecated by IETF consensus, with review by the MPLS working group (or designated experts if the working group or a successor does not exist). An RFC with at least Informational status is required. 🌸

The RFC will direct IANA to mark the label value as "deprecated" in the registry, but it will not release it at this stage 🙈

Deprecating means that no further specifications using the deprecated value will be documented. 💀

At the same time, this is an indication to vendors not to include the deprecated value in new implementations, and to operators to avoid including it in new deployments. 🧚

b. Twelve months after the RFC deprecating the label value is published, an IETF-wide survey may be conducted to determine if the deprecated label value is still in use. If the survey indicates that the deprecated label value is in use, the survey may be repeated after an additional 6 months. 🍓

c. If the survey indicates that a deprecated label value is not in use, 24 months after the RFC that deprecated the label value was published, publication may be requested of an IETF Standards Track Internet-Draft that retires the deprecated label value. This document will request that IANA release the label value for future use and assignment. 👑

4. Updated RFCs

okay the following RFCs contain references to the term "reserved labels" 💜

• [RFC3032] ("MPLS Label Stack Encoding")
• [RFC3038] ("VCID Notification over ATM link for LDP")
• [RFC3209] ("RSVP-TE: Extensions to RSVP for LSP Tunnels")
• [RFC3811] ("Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management")
• [RFC4182] ("Removing a Restriction on the use of MPLS Explicit NULL")
• [RFC4928] ("Avoiding Equal Cost Multipath Treatment in MPLS Networks")
• [RFC5331] ("MPLS Upstream Label Assignment and Context-Specific Label Space")
• [RFC5586] ("MPLS Generic Associated Channel")
• [RFC5921] ("A Framework for MPLS in Transport Networks")
• [RFC5960] ("MPLS Transport Profile Data Plane Architecture")
• [RFC6391] ("Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network")
• [RFC6478] ("Pseudowire Status for Static Pseudowires")
• [RFC6790] ("MPLS Entropy Labels")

All such references should be read as "special-purpose labels" 🎀

5. IANA Considerations

IANA has made the following changes and additions to its registration of MPLS labels 🌈

1. Changed the name of the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry to "Special-Purpose MPLS Label Values".
2. Changed the allocation policy for the "Special-Purpose MPLS Label Values" registry to Standards Action.
3. Assigned value 15 from the "Special-Purpose MPLS Label Values" registry, naming it the "Extension Label" and citing this document as the reference.
4. Created a new registry called the "Extended Special-Purpose MPLS Label Values" registry. The registration procedure is Standards Action, and the ranges for this registry are as shown in Table 1 (using terminology from [RFC5226]). Early allocation following the policy defined in [RFC7120] is allowed only for those values assigned by Standards Action. ✨

   +---------------------+---------------------------------------------+
   | Range               | Allocation Policy                           |
   +---------------------+---------------------------------------------+
   | 0 - 15              | Reserved.  Never to be made available for   |
   |                     | allocation.                                 |
   |                     |                                             |
   | 16 - 239            | Unassigned                                  |
   |                     |                                             |
   | 240 - 255           | Reserved for Experimental Use               |
   |                     |                                             |
   | 256 - 1048575       | Reserved.  Not to be made available for     |
   |                     | allocation without a new Standards Track    |
   |                     | RFC to define an allocation policy.         |
   +---------------------+---------------------------------------------+

Table 1

6. Security Considerations

⚠️ Okay bestie, this one is important, so read it carefully 💀

This document does not make a large change to the operation of the MPLS data plane, and security considerations are largely unchanged from those specified in the MPLS Architecture [RFC3031] and in the MPLS and GMPLS Security Framework [RFC5920]. 🔥

However, it should be noted that increasing the label stack can cause packet fragmentation and may also make packets unprocessable by some implementations. This document provides a protocol-legal way to increase the label stack through the insertion of additional {XL,ESPL} pairs at a greater rate than insertion of single "rogue" labels. This might provide a way to attack some nodes in a network that can only process label stacks of a certain size without violating the protocol rules.

This document also describes events that may cause an LSR to issue event logs at a per-packet rate. It is critically important that implementations rate-limit such logs. 🚨

7. Acknowledgments

Thanks to Pablo Frank and Lizhong Jin for useful discussions. Thanks to Curtis Villamizar, Mach Chen, Alia Atlas, Eric Rosen, Maria Napierala, Roni Even, Stewart Bryant, John Drake, Andy Malis, and Tom Yu for useful comments. 🫶🌸

8. References

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

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

[RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. Doolan, "VCID Notification over ATM link for LDP", RFC 3038, January 2001.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[RFC3811] Nadeau, T., Ed., and J. Cucchiara, Ed., "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.

[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS Explicit NULL", RFC 4182, September 2005.

[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 4928, June 2007.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.

[RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.

[RFC6391] Bryant, S., Ed., Filsfils, C., Drafz, U., Kompella, V., Regan, J., and S. Amante, "Flow-Aware Transport of Pseudowires over an MPLS Packet Switched Network", RFC 6391, November 2011.

[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.

[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014.

8.2. Informative References

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

[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.

[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.

Authors' Addresses

Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 US

EMail: kireeti.kompella@gmail.com

Loa Andersson Huawei

EMail: loa@mail01.huawei.com

Adrian Farrel Juniper Networks

EMail: adrian@olddog.co.uk