One document matched: draft-kompella-mpls-special-purpose-labels-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<rfc ipr="trust200902" category="std" updates='3032'>
  <front>
    <title abbrev='MPLS Reserved Labels'>
      Allocating and Retiring MPLS Reserved Labels
    </title>

    <author initials="K." surname="Kompella" fullname="Kireeti Kompella">
      <organization>Contrail Systems</organization>
      <address>
	<postal>
	  <street>2350 Mission College Blvd.</street>
	  <city>Santa Clara</city>
	  <region>CA</region>
	  <code>95054</code>
	  <country>US</country>
	</postal>
	<email>kireeti.kompella@gmail.com</email>
      </address>
    </author>

    <author initials="L." surname='Andersson' fullname='Loa Andersson'>
      <organization>Ericsson</organization>
      <address>
	<email>loa@pi.nu</email>
      </address>
    </author>

    <author initials="A." surname='Farrel' fullname='Adrian Farrel'>
      <organization>Juniper Networks</organization>
      <address>
	<email>afarrel@olddog.co.uk</email>
      </address>
    </author>

    <date year="2012"/>
    <area>Routing</area>
    <keyword>MPLS, reserved label</keyword>

    <abstract>
      <t>
	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.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction" anchor='intro'>
      <t>
	The specification of the Label Stack Encoding for
	Multi-Protocol Label Switching (MPLS) <xref target='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 <xref
	target='I-D.ietf-mpls-entropy-label'/>, <xref
	target='RFC5586'/> and <xref target='RFC3429'/>,
	respectively), leaving nine unassigned values from the
	original space of sixteen.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </t>

      <section anchor="conv" title="Conventions used">
	<t>
	  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 <xref target="RFC2119"/>.
	</t>
      </section>
    </section>

    <section title='Questions'>
      <t>
	In re-appraising MPLS special purpose labels, the following
	questions come to mind:
	<list style='numbers'>
	  <t>
	    What allocation policies should be applied by IANA for the
	    allocation of special purpose labels?  Should Early
	    Allocation <xref target='RFC4020'/> be allowed?  Should
	    there be labels for Experimental Use or Private Use <xref
	    target='RFC5226'/>?
	  </t>
	  <t>
	    What documentation is required for special purpose labels
	    allocated henceforth?
	  </t>
	  <t>
	    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?
	  </t>
	  <t>
	    The special purpose label value of 3 (the "Implicit Null
	    Label", <xref target='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?
	  </t>
	  <t>
	    What is a feasible mechanism to extend the space of
	    special purpose labels, should this become necessary?
	  </t>
	</list>
      </t>
    </section>

    <section title='Answers'>
      <t>
	This section provides answers to the questions posed in the
	previous section.
	<list style='numbers'>
	  <t>
	    <list style='letters'>
	      <t>
		Allocation of special purpose MPLS labels is via
		"Standards Action".
	      </t>
	      <t>
		The IANA registry will be renamed "Special Purpose
		MPLS Labels".
	      </t>
	      <t>
		Early allocation may be allowed on a case-by-case
		basis.
	      </t>
	      <t>
		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.
	      </t>
	    </list>
	  </t>
	  <t>
	    A Standards Track RFC must accompany a request for
	    allocation of special purpose labels, as per <xref
	    target='RFC5226'/>.
	  </t>
	  <t>
	    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 <xref target='deprecate'/>.
	  </t>
	  <t>
	    The use of the "implicit null label" (label 3) in the data
	    plane may be allowed, subject to approval by the MPLS WG,
	    and an accompanying Standards Track RFC that details the
	    use of the label, and a discussion of possible sources of
	    confusion between signaling and data plane, and mitigation
	    thereof.
	  </t>
	  <t>
	    The special purpose label (the "extension" label) is to be
	    set aside for the purpose of extending the space of
	    special purpose labels.  Further details are described in
	    <xref target='espml'/>.
	  </t>
	</list>
      </t>
      <t>
	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 <xref target='espml'/>.
      </t>

      <section title='Extended Special Purpose MPLS Label Values'
	       anchor='espml'>
	<t>
	  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" from a
	  new registry created by this document (see <xref
	  target='IANA'/>).  Whether or not L has the bottom-of-stack
	  bit set depends on whether other labels follow L.
	</t>
	<t>
	  IANA is asked to set aside label value 15 as the extension
	  label.
	</t>
	<t>
	  The first 16 values of the extended special purpose label
	  registry are duplicated from the pre-existing special
	  purpose label registry.  This includes the previously
	  allocated values (0-3, 7, 13, and 14), the extension label
	  value (15) allocated by this document, and the remaining
	  unallocated values (4-6 and 8-12).  Any of these values
	  present as an extended special purpose label MUST be
	  interpreted 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).
	</t>
      </section>

      <section title='Process for Retiring Special Purpose Labels'
	       anchor='deprecate'>
	<t>
	  <list style='letters'>
	    <t>
	      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.
	      <vspace blankLines='1' />
	      The RFC will direct the IANA to mark the label value as
	      "deprecated" in the registry, but will not release it at
	      this stage.
	      <vspace blankLines='1' />
	      Deprecating means that no further specifications using
	      the deprecated value will be documented.
	      <vspace blankLines='1' />
	      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.
	    </t>
	    <t>
	      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.
	    </t>
	    <t>
	      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.
	    </t>
	  </list>
	</t>
      </section>
    </section>

    <section title='IANA Considerations'
	     anchor='IANA'>
      <t>
	This document requests IANA to make the following changes and
	additions to its registration of MPLS Labels.
	<list style='numbers'>
	  <t>
	    Change the name of the "Multiprotocol Label Switching
	    Architecture (MPLS) Label Values" registry to the "Special
	    Purpose MPLS Label Values".
	  </t>
	  <t>
	    Change the allocations policy for the "Special Purpose MPLS
	    Label Values" registry to Standards Action.
	  </t>
	  <t>
	    Assign label 15 from the "Special Purpose MPLS Label Values"
	    registry, naming it the "extension label", and citing this
	    document as the reference.
	  </t>
	  <t>
	    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 <xref target='RFC5226'/>).  Early
	    allocation following the policy defined in <xref
	    target='RFC4020'/> is allowed only for those values
	    assigned by Standards Action.
	  </t>
	</list>
      </t>
      <texttable anchor='alloc-pol'>
        <ttcol align='left' width='30%'>Range</ttcol>
        <ttcol align='left'>Allocation Policy</ttcol>
        <c>0 - 15</c>
	<c>
	  Reserved.  Not to be allocated.
	  Meaning is defined by values in the "Special
	  Purpose MPLS Label Values" registry.
	</c>
        <c>16 - 1048559</c> <c>Standards Action</c>
        <c>1048560 - 1048575</c> <c>Experimental</c>
      </texttable>
    </section>

  <section title='Security Considerations'>
    <t>
      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 <xref
      target='RFC3031'/> and in the MPLS and GMPLS Security Framework
      <xref target='RFC5920'/>.
    </t>
    <t>
      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.
    </t>
  </section>
  </middle>

  <back>
    <references title='Normative References'>
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.3031'?>
      <?rfc include='reference.RFC.3032'?>
      <?rfc include='reference.RFC.4020'?>
      <?rfc include='reference.RFC.5226'?>
      <?rfc include='reference.RFC.5920'?>
    </references>
    <references title='Informational References'>
      <?rfc include='reference.RFC.3429'?>
      <?rfc include='reference.RFC.5586'?>
      <?rfc include='reference.I-D.ietf-mpls-entropy-label'?>
    </references>
  </back>

</rfc>