<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-isis-mpls-elc-02" ipr="trust200902">
  <front>
    <title abbrev="Signalling ELC using IS-IS">Signaling Entropy Label
    Capability 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="Sriganesh Kini" initials="S.K" surname="Kini">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>sriganesh.kini@ericsson.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Siva Sivabalan" initials="S.S" surname="Sivabalan">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>

        <email>msiva@cisco.com</email>

        <uri/>
      </address>
    </author>

    <author fullname="Clarence Filsfils" initials="C.F." surname="Filsfils">
      <organization>Cisco</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>cfilsfil@cisco.com</email>

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

    <author fullname="Stephane Litkowski" initials="S.L." surname="Litkowski">
      <organization>Orange</organization>

      <address>
        <postal>
          <street/>

          <street/>

          <city/>

          <code/>

          <country/>
        </postal>

        <email>stephane.litkowski@orange.com</email>

        <uri/>
      </address>
    </author>

    <date month="" year="2016"/>

    <area>Routing Area</area>

    <workgroup>ISIS Working Group</workgroup>

    <keyword>Sample</keyword>

    <keyword>Draft</keyword>

    <abstract>
      <t>Multi Protocol Label Switching (MPLS) has defined a mechanism to load
      balance traffic flows using Entropy Labels (EL). An ingress LSR cannot
      insert ELs for packets going into a given tunnel unless an egress LSR
      has indicated via signaling that it can process ELs on that tunnel. This
      draft defines a mechanism to signal that capability using IS-IS. This
      mechanism is useful when the label advertisement is also done via
      IS-IS.</t>
    </abstract>

    <note 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>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Multi Protocol Label Switching (MPLS) has defined a method in <xref
      target="RFC6790"/> to load balance traffic flows using Entropy Labels
      (EL). An ingress LSR cannot insert ELs for packets going into a given
      tunnel unless an egress LSR has indicated that it can process ELs on
      that tunnel. <xref target="RFC6790"/> defines the signaling of this
      capability (a.k.a., Entropy Label Capability - ELC) via signaling
      protocols. Recently, mechanisms are being defined to signal labels via
      link state Interior Gateway Protocols (IGP) such as IS-IS <xref
      target="I-D.ietf-isis-segment-routing-extensions"/> . In such scenario
      the signaling mechanisms defined in <xref target="RFC6790"/> are
      inadequate. This draft defines a mechanism to signal the ELC using
      IS-IS. This mechanism is useful when the label advertisement is also
      done via IS-IS. In addition, in the cases where stacked LSPs are used
      for whatever reasons (e.g., SPRING-MPLS <xref
      target="I-D.ietf-spring-segment-routing-mpls"/>), it would be useful for
      ingress LSRs to know each LSR's capability of reading the maximum label
      stack deepth. This capability, referred to as Readable Label Deepth
      Capability (RLDC) can be used by ingress LSRs to determine whether it's
      necessary to insert an EL for a given LSP tunnel in the case where there
      has already been at least one EL in the label stack <xref
      target="I-D.ietf-mpls-spring-entropy-label"/> . Of course, even it has
      been determined that it's neccessary to insert an EL for a given LSP
      tunnel, if the egress LSR of that LSP tunnel has not yet indicated that
      it can process ELs for that tunnel, the ingress LSR MUST NOT include an
      entropy label for that tunnel as well.</t>
    </section>

    <section anchor="Teminology" title="Terminology">
      <t>This memo makes use of the terms defined in <xref target="RFC6790"/>
      and <xref target="RFC4971"/>.</t>
    </section>

    <section anchor="Advertising" title="Advertising ELC Using IS-IS">
      <t/>

      <t>The IS-IS Router CAPABILITY TLV as defined in <xref
      target="RFC4971"/> is used by IS-IS routers to announce their
      capabilities. A new sub-TLV of this TLV, called ELC sub-TLV is defined
      to advertise the capability of the router to process the ELs. It is
      formatted as described in <xref target="RFC5305"/> with a Type code to
      be assigned by IANA and a Length of zero. The scope of the advertisement
      depends on the application but it is RECOMMENDED that it SHOULD be
      domain-wide. If a router has multiple linecards, the router MUST NOT
      advertise the ELC unless all of the linecards are capable of processing
      ELs.</t>

      <t><figure>
          <artwork><![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=TBD1    |    Length=0   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 1: ELC sub-TLV Format]]></artwork>
        </figure></t>
    </section>

    <section title="Advertising RLDC Using IS-IS">
      <t>A new sub-TLV of the IS-IS Router CAPABILITY TLV, called RLDC sub-TLV
      is defined to advertise the capability of the router to read the maximum
      label stack depth. As shown in Figure 2, it is formatted as described in
      <xref target="RFC5305"/> with a Type code to be assigned by IANA and a
      Length of one. The Value field is set to the maximum readable label
      stack deepth in the range between 1 to 255. The scope of the
      advertisement depends on the application but it is RECOMMENDED that it
      SHOULD be domain-wide. If a router has multiple linecards with different
      capabilities of reading the maximum label stack deepth, the router MUST
      advertise the smallest one in the RLDC sub-TLV. </t>

      <t><figure>
          <artwork><![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=TBD2    |   Length=1    |     RLD       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        Figure 2: RLDC sub-TLV Format]]></artwork>
        </figure></t>
    </section>

    <section title="Usage and Applicability">
      <t>The ELC is used by ingress LSRs to determine whether an EL could be
      inserted into a given LSP tunnel. The RLDC is used by ingress LSRs to
      determine whether it's necessary to insert an EL for a given LSP tunnel
      in the case where there has already been at least one EL in the label
      stack. This document only describes how to signal the ELC and RLDC using
      IS-IS. As for how to apply those capabilities when inserting EL(s) into
      LSP tunnel(s), it's outside the scope of this document and accordingly
      would be described in <xref
      target="I-D.ietf-mpls-spring-entropy-label"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Yimin Shen, George Swallow, Acee
      Lindem and Carlos Pignataro for their valuable comments.</t>

      <!---->
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes a request to IANA to allocate two sub-TLV types
      within the IS-IS Router Capability TLV.</t>

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations as described in <xref target="RFC4971"/>
      is appliable to this document. This document does not introduce any new
      security risk.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

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

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-mpls-spring-entropy-label"?>

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

      <?rfc include="reference.I-D.ietf-spring-segment-routing-mpls"?>

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

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