Allocating and Retiring MPLS Reserved Labels

Abstract

There are a limited number of reserved labels defined for Multi-Protocol Label Switching. Thus one must be cautious in the allocation of new reserved labels, yet at the same time allow forward progress when a new reserved label is called for. This memo suggests some procedures to follow in the allocation and retirement of reserved labels.

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 March 30, 2013.

Copyright Notice

Copyright (c) 2012 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. Proposal
• 4. IANA Considerations
• 5. References
• Author's Address

1. Introduction

[RFC3032] defined four reserved label values for Multi-Protocol Label Switching (MPLS), namely, 0 to 3, and set aside values 4 through 15 for future use. These labels have special significance in both the control and data plane. Since then, two further values have been allocated, leaving ten unassigned values from the original space of sixteen.

While the allocation of two out of the remaining twelve reserved label values in the space of about 12 years is not in itself a cause for concern, the scarcity of reserved labels is. Furthermore, many of the reserved labels require special processing by forwarding hardware, changes to which are often expensive, and sometimes impossible. Thus, documenting a newly allocated reserved label value is important.

This memo outlines some of the issues in allocating and retiring reserved label values, and will eventually suggest mechanisms to address these. Furthermore, this memo proposes a means of extending the space of reserved 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

1. How should reserved labels be allocated? The current IANA number space for "MPLS Label Values" has the allocation policy of "IETF Consensus". Would "Expert Review" be better? Should the name of this space be changed to reflect its use? Should there be Early Allocation? Experimental Use? Private Use?
2. What documentation is required for reserved labels allocated henceforth?
3. Should a reserved label ever be retired? What criteria are relevant here? What procedures and time frames are appropriate?
4. The reserved label value of 3 is only used in signaling, never in the data plane. Could it (and should it) be used in the data plane? If so, how?
5. What is a feasible mechanism to extend the space of reserved labels, should this become necessary?

3. Proposal

To answer question 5 from the previous section, the following proposal is made: set aside label value 15 (the "extension" label) for the purpose of extending the space of reserved labels. An extension label 15 MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an "extended reserved label". Furthermore, the interpretation and special processing of such labels MUST be documented, and they MUST be registered with IANA (policies TBD).

A further question to be settled in this regard is whether a "plain" reserved label retains its meaning if it follows the extension label. That is, does a label value of 0 mean "Explicit IPv4 NULL" whether or not it is preceded by an extension label? The suggestion here is "yes" for the currently allocated reserved labels (i.e., 0-3, 7, 13, and 14). The documentation accompanying a newly allocated reserved label MUST say whether or not it retains its meaning if preceded by the extension label.

4. IANA Considerations

There is already an IANA registry for MPLS label values. This memo may eventually suggest:

1. a change in the name of the registry to "Reserved MPLS Label Values
2. some changes to the procedures for allocating values
3. a new registry for "Extended Reserved MPLS Label Values".

5. References

Author's Address