draft-kompella-mpls-special-purpose-labels-02.txt   draft-kompella-mpls-special-purpose-labels-03.txt 
Network Working Group K. Kompella Network Working Group K. Kompella
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 3032, 3038, 3209, 3811, 4182, L. Andersson Updates: 3032, 3038, 3209, 3811 (if approved) L. Andersson
4928, 5331, 5586, 5921, 5960, 6391, Huawei Intended status: Standards Track Huawei
6478, 6790 (if approved) A. Farrel Expires: November 28, 2013 A. Farrel
Intended status: Standards Track Juniper Networks Juniper Networks
Expires: September 16, 2013 March 15, 2013 May 27, 2013
Allocating and Retiring Special Purpose MPLS Labels Allocating and Retiring Special Purpose MPLS Labels
draft-kompella-mpls-special-purpose-labels-02 draft-kompella-mpls-special-purpose-labels-03
Abstract Abstract
Some MPLS labels have been allocated for specific purposes. A block 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 of labels (0-15) has been set aside to this end, and are commonly
called "reserved labels". They will be called "special purpose called "reserved labels". They will be called "special purpose
labels" in this document. As there are only 16 of these labels, labels" in this document. As there are only 16 of these labels,
caution is needed in the allocation of new special purpose 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. yet at the same time allow forward progress when one is called for.
This memo defines some procedures to follow in the allocation and This memo defines some procedures to follow in the allocation and
retirement of special purpose labels, as well as a method to extend retirement of special purpose labels, as well as a method to extend
the special purpose label space. Finally, this memo renames the IANA the special purpose label space. Finally, this memo renames the IANA
registry for these labels to "Special Purpose MPLS Label Values", and registry for these labels to "Special Purpose MPLS Label Values", and
creates a new one called the "Extended Special Purpose MPLS Label creates a new one called the "Extended Special Purpose MPLS Label
Values" registry. Values" registry.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 16, 2013. This Internet-Draft will expire on November 28, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . 3
2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Extended Special Purpose MPLS Label Values . . . . . . . . 5 3.1. Extended Special Purpose MPLS Label Values . . . . . . . 4
3.2. Process for Retiring Special Purpose Labels . . . . . . . 6 3.2. Process for Retiring Special Purpose Labels . . . . . . . 5
4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informational References . . . . . . . . . . . . . . . . . 12 7.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The specification of the Label Stack Encoding for Multi-Protocol The specification of the Label Stack Encoding for Multi-Protocol
Label Switching (MPLS) [RFC3032] defined four special purpose label Label Switching (MPLS) [RFC3032] defined four special purpose label
values (0 to 3), and set aside values 4 through 15 for future use. 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 These labels have special significance in both the control and the
data plane. Since then, three further values have been allocated data plane. Since then, three further values have been allocated
(values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429], (values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429],
respectively), leaving nine unassigned values from the original space respectively), leaving nine unassigned values from the original space
skipping to change at page 5, line 12 skipping to change at page 3, line 44
5. What is a feasible mechanism to extend the space of special 5. What is a feasible mechanism to extend the space of special
purpose labels, should this become necessary? purpose labels, should this become necessary?
3. Answers 3. Answers
This section provides answers to the questions posed in the previous This section provides answers to the questions posed in the previous
section. section.
1. 1.
A. Allocation of special purpose MPLS labels is via "Standards a. Allocation of special purpose MPLS labels is via "Standards
Action". Action".
B. The IANA registry will be renamed "Special Purpose MPLS b. The IANA registry will be renamed "Special Purpose MPLS
Labels". Labels".
C. Early allocation may be allowed on a case-by-case basis. c. Early allocation may be allowed on a case-by-case basis.
D. The current space of 16 special purpose labels is too small d. The current space of 16 special purpose labels is too small
for setting aside value for experimental or private use. for setting aside value for experimental or private use.
However, the extended special purpose labels registry created However, the extended special purpose labels registry created
by this document has enough space, and this document defines by this document has enough space, and this document defines
a range for experimental use. a range for experimental use.
2. A Standards Track RFC must accompany a request for allocation of 2. A Standards Track RFC must accompany a request for allocation of
special purpose labels, as per [RFC5226]. Standards Action special purpose labels, as per [RFC5226].
3. The retirement of a special purpose MPLS label value must follow 3. The retirement of a special purpose MPLS label value must follow
a strict and well-documented process. This is necessary since we a strict and well-documented process. This is necessary since we
must avoid orphaning the use of this label value in existing must avoid orphaning the use of this label value in existing
deployments. This process is detailed in Section 3.2. deployments. This process is detailed in Section 3.2.
4. The use of the "implicit null label" (label 3) in the data plane 4. For now, the use of the "implicit null label" (label 3) in the
may be allowed, subject to approval by the MPLS WG, and an data plane will not be allowed. If this decision is revisited
accompanying Standards Track RFC that details the use of the later, an accompanying Standards Track RFC that details the use
label, and a discussion of possible sources of confusion between of the label, a discussion of possible sources of confusion
signaling and data plane, and mitigation thereof. between signaling and data plane, and mitigation thereof.
5. The special purpose label (the "extension" label) is to be set 5. A special purpose label (the "extension" label, label 15) is to
aside for the purpose of extending the space of special purpose be set aside for the purpose of extending the space of special
labels. Further details are described in Section 3.1. purpose labels. Further details are described in Section 3.1.
A further question to be settled in this regard is whether a A further question to be settled in this regard is whether a
"regular" special purpose label retains its meaning if it follows the "regular" special purpose label retains its meaning if it follows the
extension label; see Section 3.1. extension label; see Section 3.1.
3.1. Extended Special Purpose MPLS Label Values 3.1. Extended Special Purpose MPLS Label Values
An extension label MUST be followed by another label L (and thus MUST 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 have the bottom-of-stack bit clear). L MUST be interpreted as an
"extended special purpose label" from a new registry created by this "extended special purpose label" and interpreted as defined in a new
document (see Section 5). Whether or not L has the bottom-of-stack registry created by this document (see Section 5). Whether or not L
bit set depends on whether other labels follow L. Only L is has the bottom-of-stack bit set depends on whether other labels
interpreted as an extended special purpose label; labels following L follow L. The extension label only assigns special meaning to L. A
are interpreted as normal. label after L (if any) is parsed as usual, and thus may be a regular
label, a special purpose label or (if prefixed by another extension
label) an extended special purpose label.
IANA is asked to set aside label value 15 as the extension label. IANA is asked to set aside label value 15 as the extension label.
The first 16 values of the extended special purpose label registry Values 0-6 and 8-15 of the extended special purpose label registry
are duplicated from the pre-existing special purpose label registry. are set aside as reserved; these MUST NOT appear in the data plane.
This includes the previously allocated values (0-3, 7, 13, and 14), Label 7 (when received) retains its meaning as ELI whether a regular
the extension label value (15) allocated by this document, and the or an extended special purpose label; however, an implementation
remaining unallocated values (4-6 and 8-12). Any of these values SHOULD NOT insert a label of 7 as an extended special purpose label,
present as an extended special purpose label MUST be interpreted preferring instead to send 7 as a regular special purpose label.
exactly as it would if it was presented as a special purpose label.
In particular, an arbitrary string of consecutive extension labels is
legal, and semantically equivalent to a single extension label (note
that this string of extension labels MUST be followed by an extended
special purpose label that is not the extension label).
3.2. Process for Retiring Special Purpose Labels 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 a. A label value that has been assigned from the "Special Purpose
MPLS Label Values" may be deprecated by IETF consensus with MPLS Label Values" may be deprecated by IETF consensus with
review by the MPLS working group (or designated experts if the review by the MPLS working group (or designated experts if the
working group or a successor does not exist). An RFC with at working group or a successor does not exist). An RFC with at
least Informational status is required. least Informational status is required.
The RFC will direct the IANA to mark the label value as The RFC will direct the IANA to mark the label value as
"deprecated" in the registry, but will not release it at this "deprecated" in the registry, but will not release it at this
stage. stage.
skipping to change at page 8, line 14 skipping to change at page 5, line 50
4. Updated RFCs 4. Updated RFCs
The following RFCs contain references to the term "reserved labels": The following RFCs contain references to the term "reserved labels":
[RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID [RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID
Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP
Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a
Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment
in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921] in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921]
("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane ("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane
Architecture"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391] Architecture"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391] ("FAT-
("FAT-PW"), and [RFC6478] ("Pseudowire Status for Static PW"), and [RFC6478] ("Pseudowire Status for Static Pseudowires").
Pseudowires"). All such references should be read as "special All such references should be read as "special purpose labels".
purpose labels".
5. IANA Considerations 5. IANA Considerations
This document requests IANA to make the following changes and This document requests IANA to make the following changes and
additions to its registration of MPLS Labels. additions to its registration of MPLS Labels.
1. Change the name of the "Multiprotocol Label Switching 1. Change the name of the "Multiprotocol Label Switching
Architecture (MPLS) Label Values" registry to the "Special Architecture (MPLS) Label Values" registry to the "Special
Purpose MPLS Label Values". Purpose MPLS Label Values".
skipping to change at page 9, line 32 skipping to change at page 6, line 32
4. Assign label 15 from the "Special Purpose MPLS Label Values" 4. Assign label 15 from the "Special Purpose MPLS Label Values"
registry, naming it the "extension label", and citing this registry, naming it the "extension label", and citing this
document as the reference. document as the reference.
5. Create a new registry called the "Extended Special Purpose MPLS 5. Create a new registry called the "Extended Special Purpose MPLS
Label Values" registry. The ranges and allocation policies for Label Values" registry. The ranges and allocation policies for
this registry are as follows (using terminology from [RFC5226]). this registry are as follows (using terminology from [RFC5226]).
Early allocation following the policy defined in [RFC4020] is Early allocation following the policy defined in [RFC4020] is
allowed only for those values assigned by Standards Action. allowed only for those values assigned by Standards Action.
+---------------------+---------------------------------------------+ +------------------+------------------------------------------------+
| Range | Allocation Policy | | Range | Allocation Policy |
+---------------------+---------------------------------------------+ +------------------+------------------------------------------------+
| 0, 1, 2, 3, 7, 13, | Reserved. Not to be allocated. Meaning is | | 0 - 6, 8 - 15 | Reserved. Not to be allocated. MUST NOT |
| 14, 15 | defined by values in the "Special Purpose | | | appear in the data plane. |
| | MPLS Label Values" registry. | | | |
| | | | 7 | Allocated; meaning is ELI [RFC6790] |
| 4, 5, 6, 8, 9, 10, | Standards Action (see Note) | | | |
| 11, 12 | | | 16 - TBD1 | Standards Action |
| | | | | |
| 16 - 1048559 | Standards Action | | TBD1+1 - TBD2 | Reserved |
| | | | | |
| 1048560 - 1048575 | Experimental | | TBD2+1 - 1048559 | First Come, First Served |
+---------------------+---------------------------------------------+ | | |
| 1048560 - | Experimental |
| 1048575 | |
+------------------+------------------------------------------------+
Table 1 Table 1
6. Security Considerations 6. Security Considerations
This document does not make a large change to the operation of the This document does not make a large change to the operation of the
MPLS data plane and security considerations are largely unchanged MPLS data plane and security considerations are largely unchanged
from those specified in the MPLS architecture [RFC3031] and in the from those specified in the MPLS architecture [RFC3031] and in the
MPLS and GMPLS Security Framework [RFC5920]. MPLS and GMPLS Security Framework [RFC5920].
skipping to change at page 11, line 20 skipping to change at page 7, line 33
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. [RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P.
Doolan, "VCID Notification over ATM link for LDP", Doolan, "VCID Notification over ATM link for LDP", RFC
RFC 3038, January 2001. 3038, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual
Conventions (TCs) for Multiprotocol Label Switching (MPLS) Conventions (TCs) for Multiprotocol Label Switching (MPLS)
Management", RFC 3811, June 2004. Management", RFC 3811, June 2004.
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
Standards Track Code Points", BCP 100, RFC 4020, Standards Track Code Points", BCP 100, RFC 4020, February
February 2005. 2005.
[RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS
Explicit NULL", RFC 4182, September 2005. Explicit NULL", RFC 4182, September 2005.
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128, Cost Multipath Treatment in MPLS Networks", BCP 128, RFC
RFC 4928, June 2007. 4928, June 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", Label Assignment and Context-Specific Label Space", RFC
RFC 5331, August 2008. 5331, August 2008.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks", Berger, "A Framework for MPLS in Transport Networks", RFC
RFC 5921, July 2010. 5921, July 2010.
[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
Profile Data Plane Architecture", RFC 5960, August 2010. Profile Data Plane Architecture", RFC 5960, August 2010.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391, over an MPLS Packet Switched Network", RFC 6391, November
November 2011. 2011.
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci,
"Pseudowire Status for Static Pseudowires", RFC 6478, "Pseudowire Status for Static Pseudowires", RFC 6478, May
May 2012. 2012.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, November 2012. RFC 6790, November 2012.
7.2. Informational References 7.2. Informational References
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS) Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions", RFC 3429, Operation and Maintenance (OAM) Functions", RFC 3429,
skipping to change at page 13, line 6 skipping to change at page 9, line 4
[RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for
Multiprotocol Label Switching Architecture (MPLS) Multiprotocol Label Switching Architecture (MPLS)
Operation and Maintenance (OAM) Functions", RFC 3429, Operation and Maintenance (OAM) Functions", RFC 3429,
November 2002. November 2002.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009. Associated Channel", RFC 5586, June 2009.
Authors' Addresses Authors' Addresses
Kireeti Kompella Kireeti Kompella
Juniper Networks Juniper Networks
1133 Innovation Way 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: kireeti.kompella@gmail.com Email: kireeti.kompella@gmail.com
Loa Andersson Loa Andersson
Huawei Huawei
Email: loa@mail01.huawei.com Email: loa@mail01.huawei.com
 End of changes. 26 change blocks. 
84 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/