One document matched: draft-kompella-mpls-reserved-labels-01.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>

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

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

  <middle>
    <section title="Introduction" anchor='intro'>
      <t>
	<xref target='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.
      </t>
      <t>
	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.
      </t>
      <t>
	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.
      </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>
	<list style='numbers'>
	  <t>
	    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?
	  </t>
	  <t>
	    What documentation is required for reserved labels allocated
	    henceforth?
	  </t>
	  <t>
	    Should a reserved label ever be retired?  What criteria are
	    relevant here?  What procedures and time frames are
	    appropriate?
	  </t>
	  <t>
	    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?
	  </t>
	  <t>
	    What is a feasible mechanism to extend the space of reserved
	    labels, should this become necessary?
	  </t>
	</list>
      </t>
    </section>

    <section title='Proposal'>
      <t>
	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).
      </t>
      <t>
	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.
      </t>
    </section>

    <section title='IANA Considerations'>
      <t>
	There is already an IANA registry for MPLS label values.  This
	memo may eventually suggest:
	<list style='numbers'>
	  <t>
	    a change in the name of the registry to "Reserved MPLS Label
	    Values
	  </t>
	  <t>some changes to the procedures for	allocating values</t>
	  <t>a new registry for "Extended Reserved MPLS Label Values".</t>
	</list>
      </t>
    </section>
  </middle>

  <back>
    <references title='Normative References'>
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.3032'?>
    </references>
  </back>

</rfc>