Internet Engineering Task Force (IETF) K. Kompella
Request for Comments: 7274 Juniper Networks
Updates: 3032, 3038, 3209, 3811, 4182, 4928, 5331, L. Andersson
 5586, 5921, 5960, 6391, 6478, 6790 Huawei
Category: Standards Track A. Farrel
ISSN: 2070-1721 Juniper Networks
 June 2014
 Allocating and Retiring Special-Purpose MPLS Labels
Abstract
 Some MPLS labels have been allocated for specific purposes. A block
 of labels (0-15) has been set aside to this end; these labels are
 commonly called "reserved labels". They will be called "special-
 purpose labels" in this document.
 As there are only 16 of these special-purpose labels, caution is
 needed in the allocation of new special-purpose labels; yet, at the
 same time, forward progress should be allowed when one is called for.
 This memo defines new procedures for the allocation and retirement of
 special-purpose labels, as well as a method to extend the special-
 purpose label space and a description of how to handle extended
 special-purpose labels in the data plane. Finally, this memo renames
 the IANA registry for special-purpose labels to "Special-Purpose MPLS
 Label Values" and creates a new registry called the "Extended
 Special-Purpose MPLS Label Values" registry.
 This document updates a number of previous RFCs that use the term
 "reserved label". Specifically, this document updates 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.
 This document is a product of the Internet Engineering Task Force
 (IETF). It represents the consensus of the IETF community. It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG). Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 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) in effect on the date of
 publication of this document. Please review these documents
 carefully, as 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 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
 The MPLS Label Stack Encoding specification [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 and the data plane. Since then, three further values
 have been allocated (values 7, 13, and 14 in [RFC6790], [RFC5586],
 and [RFC3429], respectively), leaving nine unassigned values from the
 original space of sixteen.
 While the allocation of three out of the remaining twelve special-
 purpose label values in the space of about 12 years is not in itself
 a cause for concern, the scarcity of special-purpose labels is.
 Furthermore, many of the special-purpose labels require special
 processing by forwarding hardware, changes to which are often
 expensive and sometimes impossible. Thus, documenting a newly
 allocated special-purpose label value is important.
 This memo outlines some of the issues in allocating and retiring
 special-purpose label values and defines mechanisms to address these.
 This memo 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 are introduced:
 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, the following 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 provides answers to the questions posed in the previous
 section.
 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 in this regard was
 whether a "regular" special-purpose label retains its meaning if it
 follows the XL. The answer to this question is provided in
 Section 3.1.
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 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 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 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 not at the top
 of stack. For load-balancing decisions, see Answer 6 in Section 3.
3.1.2. Choosing a New Special-Purpose Label
 When allocating a new special-purpose label, protocol designers
 should consider whether they could use an extended special-purpose
 label. Doing so would help to preserve the scarce resources of
 "normal" special-purpose labels for use in cases where minimizing the
 size of the label stack is particularly important.
3.2. Process for Retiring Special-Purpose Labels
 While the following process is defined for the sake of completeness,
 note that retiring special-purpose labels is difficult. 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 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
 The following RFCs contain references to the term "reserved labels":
 o [RFC3032] ("MPLS Label Stack Encoding")
 o [RFC3038] ("VCID Notification over ATM link for LDP")
 o [RFC3209] ("RSVP-TE: Extensions to RSVP for LSP Tunnels")
 o [RFC3811] ("Definitions of Textual Conventions (TCs) for
 Multiprotocol Label Switching (MPLS) Management")
 o [RFC4182] ("Removing a Restriction on the use of MPLS Explicit
 NULL")
 o [RFC4928] ("Avoiding Equal Cost Multipath Treatment in MPLS
 Networks")
 o [RFC5331] ("MPLS Upstream Label Assignment and Context-Specific
 Label Space")
 o [RFC5586] ("MPLS Generic Associated Channel")
 o [RFC5921] ("A Framework for MPLS in Transport Networks")
 o [RFC5960] ("MPLS Transport Profile Data Plane Architecture")
 o [RFC6391] ("Flow-Aware Transport of Pseudowires over an MPLS
 Packet Switched Network")
 o [RFC6478] ("Pseudowire Status for Static Pseudowires")
 o [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
 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