Allocating and Retiring Special Purpose MPLS Labels
draft-ietf-mpls-special-purpose-labels-01

Abstract

Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 08, 2014.

Copyright Notice

Copyright (c) 2013 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
• 1.1. Conventions used
• 2. Questions
• 3. Answers
• 3.1. Extended Special Purpose MPLS Label Values
• 3.2. Process for Retiring Special Purpose Labels
• 4. Updated RFCs
• 5. IANA Considerations
• 6. Security Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informational References
• Authors' Addresses

1. Introduction

The specification of the Label Stack Encoding for Multi-Protocol Label Switching (MPLS) [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

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

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 [RFC4020] 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. 1. Allocation of special purpose MPLS labels is via "Standards Action".
   2. The IANA registry will be renamed "Special Purpose MPLS Labels".
   3. Early allocation may be allowed on a case-by-case basis.
   4. The current space of 16 special purpose labels is too small for setting aside value for experimental or private use. However, the extended special purpose labels 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" (label 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.
5. A special purpose label (the "extension" label, label 15) is to be 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. Thus, this document specifies that extended special purpose labels MUST NOT be used for load balancing. It is noted that existing implementations may violate this, as they do not look for extension labels and thus for extended special purpose labels. The consequence is that if extended special purpose labels are used in some packets of a flow, these packets be re-ordered. However, it is important to specify the correct behavior for future implementations, hence the use of MUST NOT.

A further question to be settled in this regard is whether a "regular" special purpose label retains its meaning if it follows the extension label; see Section 3.1.

3.1. Extended Special Purpose MPLS Label Values

An extension label MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an "extended special purpose label" 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 extension label 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 an extension label, and thus followed by an extended special purpose label.

IANA is asked to set aside label value 15 as the extension label.

Values 0-6 and 8-15 of the extended special purpose label registry are set aside as reserved; these MUST NOT appear in the data plane. Label 7 (when received) retains its meaning as ELI whether a regular or an extended special purpose label; this is to simplify the logic for transit LSRs looking for entropy labels. However, an LSR wishing to insert an entropy label SHOULD insert label 7 as a regular special purpose label, not as an extended special purpose label.

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.

1. A label value that has been assigned from the "Special Purpose MPLS Label Values" 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 the 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 deprecated value in new implementations and to operators to avoid including it in new deployments.
2. 12 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 a further 6 months.
3. 24 months after the RFC that deprecated the label value was published and if the survey indicates that deprecated label value is not in use, publication may be requested of an IETF Standards Track Internet-Draft that retires the deprecated the label value. This document will request IANA to release the label value for for future use and assignment.

4. Updated RFCs

The following RFCs contain references to the term "reserved labels": [RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921] ("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane Architecture"), [RFC6391] ("FAT-PW"), [RFC6478] ("Pseudowire Status for Static Pseudowires") and [RFC6790] ("MPLS Entropy Labels"). All such references should be read as "special purpose labels".

5. IANA Considerations

This document requests IANA to make the following changes and additions to its registration of MPLS Labels.

1. Change the name of the "Multiprotocol Label Switching Architecture (MPLS) Label Values" registry to the "Special Purpose MPLS Label Values".
2. Change the allocations policy for the "Special Purpose MPLS Label Values" registry to Standards Action.
3. Note: any new allocation from the Special Purpose MPLS Label Values registry MUST be also say whether the same value needs to be reserved in the Extended Special Purpose MPLS Label Values registry.
4. Assign label 15 from the "Special Purpose MPLS Label Values" registry, naming it the "extension label", and citing this document as the reference.
5. Create a new registry called the "Extended Special Purpose MPLS Label Values" registry. The ranges and allocation policies for this registry are as follows (using terminology from [RFC5226]). Early allocation following the policy defined in [RFC4020] is allowed only for those values assigned by Standards Action.