<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
    There has to be one entity for each item to be referenced. 
    An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-xu-isis-global-label-sid-adv-00"
     ipr="trust200902">
  <front>
    <title abbrev="">Advertising Global Labels or SIDs Using IS-IS</title>

    <author fullname="Xiaohu Xu" initials="X.X." surname="Xu">
      <organization>Huawei</organization>

      <address>
        <!--
       <postal>
         <street></street>
-->

        <!-- Reorder these if your country does things differently -->

        <!--
         <city>Soham</city>

         <region></region>

         <code></code>

         <country>UK</country>
       </postal>

       <phone>+44 7889 488 335</phone>
-->

        <email>xuxiaohu@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <author fullname="Mach Chen" initials="M.C." surname="Chen">
      <organization>Huawei</organization>

      <address>
        <!--
       <postal>
         <street></street>
-->

        <!-- Reorder these if your country does things differently -->

        <!--
         <city>Soham</city>

         <region></region>

         <code></code>

         <country>UK</country>
       </postal>

       <phone>+44 7889 488 335</phone>
-->

        <email>mach.chen@huawei.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <!--

-->

    <date year="2013"/>

    <abstract>
      <t>Segment Routing (SR) is a new MPLS paradigm in which each SR-capable
      router is required to advertise global MPLS labels or Segment IDs (SID )
      for its attached prefixes by using link-state IGPs, e.g., IS-IS. One
      major challenge associated with such global MPLS label or SID
      advertisement mechanism is how to avoid a given global MPLS label or SID
      from being allocated by different routers to different prefixes.
      Although such global label or SID allocation collision problem can be
      addressed through manual allocation , it is error-prone and nonautomatic
      therefore may not be suitable in large-scale SR network environments.
      This document proposes an alternative approach for allocating and
      advertising global MPLS labels or SIDs via IS-IS so as to eliminate the
      potential risk of label allocation collision.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Segment Routing (SR) <xref
      target="I-D.filsfils-rtgwg-segment-routing"/> is a new MPLS paradigm in
      which each SR-capable router is required to advertise global MPLS labels
      or Segment IDs (SID) for its attached prefixes by using link-state IGPs,
      e.g., IS-IS<xref target="I-D.previdi-isis-segment-routing-extensions"/>
      . One major challenge associated with such global MPLS label or SID
      advertisement mechanism is how to avoid a given global MPLS label or SID
      from being allocated by different routers to different prefixes.
      Although such global label or SID allocation collision problem can be
      addressed through manual allocation , it is error-prone and nonautomatic
      therefore may not be suitable in large-scale SR network
      environments.</t>

      <t>This document proposes an alternative approach for allocating and
      advertising global MPLS labels or SIDs via IS-IS so as to eliminate the
      potential risk of label allocation collision. The basic idea of this
      approach is to allow a particular IGP router to allocate global MPLS
      labels or SIDs for those prefixes attached to each SR-capable router and
      meanwhile advertise the corresponding label or SID bindings in the IGP
      domain scope. That particular IGP rouer is therefore refered to as a
      mapping server. As for how the mapping server know which prefixes need
      to be allocated with global labels or SIDs, it can be achieved either by
      configuration on the mapping server or by advertisement from SR-capable
      routers. In the multi-level scenario where route summarization between
      levels is enabled, the IP longest-match algorithm SHOULD be used by
      SR-capable routers when processing label or SID bindings advertised by
      the mapping server, just as the mechanism defined in <xref
      target="RFC5283"/> .</t>

      <section title="Requirements Language">
        <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">RFC 2119</xref>.</t>
      </section>
    </section>

    <section anchor="Teminology" title="Terminology">
      <t>This memo makes use of the terms defined in <xref
      target="I-D.filsfils-rtgwg-segment-routing"/> and <xref
      target="RFC4971"/>.</t>
    </section>

    <section anchor="AdvertisingL"
             title="Advertising Label Bindings for Prefixes using IS-IS">
      <t>A mapping server could uses one or more of the following TLVs to
      advertise global labels for those prefixes which need to be allocated
      with global labels.</t>

      <t><list style="symbols">
          <t>TLV-135 (IPv4) <xref target="RFC5305"/></t>

          <t>TLV-235 (MT-IPv4) <xref target="RFC5120"/></t>

          <t>TLV-236 (IPv6) <xref target="RFC5308"/></t>

          <t>TLV-237 (MT-IPv6) <xref target="RFC5120"/></t>
        </list></t>

      <t>A Label Binding Sub-TLV (TBD) as shown below is associated with a
      prefix which is contained in one of the above TLVs:</t>

      <t><figure>
          <artwork align="center"><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=TBD    |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|  Reserved   |             MPLS Label (20 bit)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t><list style="empty">
          <t>Type: TBD</t>

          <t>Length: 4</t>

          <t>P-Flag: if set, the penultimate hop router MUST perform PHP
          action on the allocated MPLS label. For a given prefix, the P-Flag
          in the Label Binding Sub-TLV MUST be set to the same value as that
          of the P-Flag in the Label Request Sub-TLV if a label request
          message (See Section 5 of this document) for that prefix is received
          by the mapping server.</t>

          <t>MPLS Label: a global label for the prefix which is carried in the
          TLV containing this sub-TLV.</t>
        </list></t>

      <t>Since the mapping server uses these TLVs for label binding
      advertisement purpose other than building the normal IP routing table,
      the Metric field MUST be set to a value larger than MAX_PATH_METRIC
      (i.e., 0xFE000000) according to the following specification as defined
      in <xref target="RFC5305"/> "...If a prefix is advertised with a metric
      larger then MAX_PATH_METRIC (0xFE000000, see paragraph 3.0), this prefix
      MUST NOT be considered during the normal SPF computation. This allows
      advertisement of a prefix for purposes other than building the normal IP
      routing table...". In addition, when propagating those TLVs across
      levels, the Label Binding Sub-TLVs contained in them MUST be
      preserved.</t>
    </section>

    <section anchor="Adv2"
             title="Advertising SID Bindings for Prefixes using IS-IS"
             toc="default">
      <t>A mapping server could uses one or more of the Extended IP
      Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and TLV-237) to
      advertise SIDs for those prefixes which need to be allocated with
      SIDs.</t>

      <t>A SID Binding Sub-TLV (TBD) as shown below is associated with a
      prefix which is contained in one of the above TLVs:</t>

      <t><figure>
          <artwork align="center"><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=TBD    |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              SID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t><list style="empty">
          <t>Type: TBD</t>

          <t>Length: 4</t>

          <t>SID: a SID for the prefix which is carried in the TLV containing
          this sub-TLV.</t>
        </list></t>

      <t>Since the mapping server uses these TLVs for label binding
      advertisement purpose other than building the normal IP routing table,
      the Metric field MUST be set to a value larger than MAX_PATH_METRIC
      (i.e., 0xFE000000). In addition, when propagating those TLVs across
      levels, the SID Binding Sub-TLVs contained in them MUST be
      preserved.</t>
    </section>

    <section anchor="Req"
             title="Requesting Label Bindings for Prefixes using IS-IS">
      <t>When advertising IP reachability information by using one of the
      Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and
      TLV-237), SR-capable IS-IS routers SHOULD mark those attached prefixes
      which need to be allocated with global labels by associating each of
      these prefixes with a Label Request sub-TLV (type code=TBD) as shown
      below. In addition, when propagating those TLVs across levels, the Label
      Request Sub-TLVs contained in them MUST be preserved.</t>

      <t><figure>
          <artwork align="center"><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=TBD    |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|                         Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t><list style="empty">
          <t>Type: TBD</t>

          <t>Length: 4</t>

          <t>P-Flag: if set, the penultimate hop router MUST perform PHP
          action on the required label.</t>
        </list>In the multi-level scenario where route summarization between
      levels is required, separate Extended IP Reachability TLVs other than
      those for IP reachability advertisement purpose SHOULD be used for label
      binding request purpose. Since these separate TLVs are not used for the
      purpose of building the normal IP routing table, the Metric field MUST
      be set to a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). In
      addition, when propagating those TLVs across levels, the Label Request
      Sub-TLVs contained in them MUST be preserved.</t>
    </section>

    <section title="Requesting SID Bindings for Prefixes using IS-IS">
      <t>When advertising IP reachability information by using one of the
      Extended IP Reachability TLVs (i.e., TLV-135, TLV-235, TLV-236 and
      TLV-237), SR-capable IS-IS routers SHOULD mark those attached prefixes
      which need to be allocated with SIDs by associating each of these
      prefixes with a SID Request sub-TLV (Type Code=TBD and Length=0)</t>

      <t>In the multi-level scenario where route summarization between levels
      is required, separate Extended IP Reachability TLVs other than those for
      IP reachability advertisement purpose SHOULD be used for SID binding
      request purpose. Since these separate TLVs are not used for the purpose
      of building the normal IP routing table, the Metric field MUST be set to
      a value larger than MAX_PATH_METRIC (i.e., 0xFE000000). In addition,
      when propagating those TLVs across levels, the SID Request Sub-TLVs
      contained in them MUST be preserved.</t>
    </section>

    <section title="Mapping Server Redundancy">
      <t>For redundancy purpose, more than one router could be configured as
      candidates for mapping servers. Each candidate for mapping servers
      SHOULD advertise its capability of being a mapping servers by using
      IS-IS Router Capability TLV. The one with the highest priority SHOULD be
      elected as the primary mapping server which is eligible to allocate and
      advertise global labels or SIDs for prefixes on behalf of SR-capable
      routers. The comparison of IS-IS System ID breaks the tie between two or
      more candidates with the same highest priority. Meanwhile, the one with
      the second highest priority SHOULD be elected as a backup mapping
      server. This backup mapping server SHOULD advertise the same label
      bindings as those advertised by the primary mapping server. In this way,
      the unnecessary changes to the data plane (i.e., MPLS forwarding table)
      of SR-capable routers can be avoided in the event of mapping server
      failover.</t>

      <t>Each candidate mapping server SHOULD advertise its capability of
      being a mapping server and the corresponding priority for mapping server
      election by attaching a Mapping Server Capability Sub-TLV (type
      code=TBD) shown as below to an IS-IS Router Capability TLV <xref
      target="RFC4971"/> with the S flag set (with domain-wide flooding
      scope).</t>

      <t><figure>
          <artwork align="center"><![CDATA[ 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type=TBD    |    Length     |    Priority   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure></t>

      <t><list style="empty">
          <t>Type: TBD</t>

          <t>Length: 1</t>

          <t>Priority: the priority for mapping server election.</t>
        </list></t>
    </section>

    <!---->

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank .</t>

      <!---->
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>TBD.</t>

      <!---->
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document does not introduce any new security considerations.</t>

      <!---->
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      <?rfc include="reference.RFC.5305"?>

      <?rfc include="reference.RFC.4971"?>

      <?rfc include="reference.RFC.5308"?>

      <?rfc include="reference.I-D.previdi-isis-segment-routing-extensions"?>

      <?rfc include="reference.RFC.5120"?>

      <?rfc include="reference.RFC.5283"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.filsfils-rtgwg-segment-routing"?>
    </references>
  </back>
</rfc>
