[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kompella-mpls-special-purpose-labels) 00 01 02 03 04 05 06 RFC 7274

Network Working Group                                        K. Kompella
Internet-Draft                                          Juniper Networks
Updates:                                                    L. Andersson
3032,3038,3209,3811,4182,4928,5331,5586,5921,5960,6391,6478,6790  Huawei
(if approved)                                                  A. Farrel
Intended status: Standards Track                        Juniper Networks
Expires: January 5, 2014                                    July 4, 2013


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

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 5, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Kompella, et al.         Expires January 5, 2014                [Page 1]

Internet-Draft         Special Purpose MPLS Labels             July 2013


   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 . . . . . . . . . . . . . . . . . . . . .  3
   2.  Questions  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Answers  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Extended Special Purpose MPLS Label Values . . . . . . . .  5
     3.2.  Process for Retiring Special Purpose Labels  . . . . . . .  6
   4.  Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informational References . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13

























Kompella, et al.         Expires January 5, 2014                [Page 2]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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























Kompella, et al.         Expires January 5, 2014                [Page 3]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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?


























Kompella, et al.         Expires January 5, 2014                [Page 4]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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
           Labels".

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

   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



Kompella, et al.         Expires January 5, 2014                [Page 5]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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

   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; however, an implementation
   SHOULD NOT insert a label of 7 as an extended special purpose label,
   preferring instead to send 7 as a regular 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.

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

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

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



Kompella, et al.         Expires January 5, 2014                [Page 6]

Internet-Draft         Special Purpose MPLS Labels             July 2013


       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.
















































Kompella, et al.         Expires January 5, 2014                [Page 7]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391]
   ("FAT-PW"), and [RFC6478] ("Pseudowire Status for Static
   Pseudowires").  All such references should be read as "special
   purpose labels".






































Kompella, et al.         Expires January 5, 2014                [Page 8]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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.

   +---------------------+---------------------------------------------+
   | Range               | Allocation Policy                           |
   +---------------------+---------------------------------------------+
   | 0 - 6, 8 - 15       | Reserved.  Not to be allocated.  MUST NOT   |
   |                     | appear in the data plane.                   |
   |                     |                                             |
   | 7                   | Allocated; meaning is ELI [RFC6790]         |
   |                     |                                             |
   | 16 - TBD1           | Standards Action                            |
   |                     |                                             |
   | TBD1+1 - TBD2       | Reserved                                    |
   |                     |                                             |
   | TBD2+1 - 1048559    | First Come, First Served                    |
   |                     |                                             |
   | 1048560 - 1048575   | Experimental                                |
   +---------------------+---------------------------------------------+

                                  Table 1






Kompella, et al.         Expires January 5, 2014                [Page 9]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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
   arbitrarily increase the label stack and so might provide a way to
   attack some nodes in a network without violating the protocol rules.







































Kompella, et al.         Expires January 5, 2014               [Page 10]

Internet-Draft         Special Purpose MPLS Labels             July 2013


7.  References

7.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. and J. Cucchiara, "Definitions of Textual
              Conventions (TCs) for Multiprotocol Label Switching (MPLS)
              Management", RFC 3811, June 2004.

   [RFC4020]  Kompella, K. and A. Zinin, "Early IANA Allocation of
              Standards Track Code Points", BCP 100, RFC 4020,
              February 2005.

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

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




Kompella, et al.         Expires January 5, 2014               [Page 11]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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

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

   [RFC6391]  Bryant, S., 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.

7.2.  Informational 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., Vigoureux, M., and S. Bryant, "MPLS Generic
              Associated Channel", RFC 5586, June 2009.






















Kompella, et al.         Expires January 5, 2014               [Page 12]

Internet-Draft         Special Purpose MPLS Labels             July 2013


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






























Kompella, et al.         Expires January 5, 2014               [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/