<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6790 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY RFC4206 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4206.xml">
<!ENTITY RFC7325 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7325.xml">
<!ENTITY RFC7855 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7855.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY SR SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing.xml">
<!ENTITY SR-MPLS SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-spring-segment-routing-mpls.xml">
<!ENTITY ISIS-ELC SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-isis-mpls-elc.xml">
<!ENTITY OSPF-ELC SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
<!ENTITY OSPF-MSD SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-segment-routing-msd.xml">
<!ENTITY ISIS-MSD SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
<!ENTITY BGP-MSD SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
<!ENTITY SR-L2-BUNDLES SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-isis-l2bundles.xml">
]>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?> version='1.0' encoding='utf-8'?>
<rfc ipr="trust200902" xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-mpls-spring-entropy-label-12" obsoletes="" updates="" indexInclude="true" ipr="trust200902" number="8662" prepTime="2019-12-04T22:14:22" scripts="Common,Latin" sortRefs="false" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-mpls-spring-entropy-label-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8662" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Entropy Labels for SPRING tunnels">Entropy label Tunnels">Entropy Label for SPRING tunnels</title> Source Packet Routing in Networking (SPRING) Tunnels</title>
    <seriesInfo name="RFC" value="8662" stream="IETF"/>
    <author initials="S" surname="Kini" fullname="Sriganesh Kini">
      <organization></organization>
      <organization showOnFrontPage="true"/>
      <address>
        <postal>
		  <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>sriganeshkini@gmail.com</email>
      </address>
    </author>
    <author initials="K" surname="Kompella" fullname="Kireeti Kompella">
      <organization>Juniper</organization>
      <organization showOnFrontPage="true">Juniper</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>kireeti@juniper.net</email>
      </address>
    </author>
    <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
      <organization>Cisco</organization>
      <organization showOnFrontPage="true">Cisco</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>msiva@cisco.com</email>
      </address>
    </author>
    <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
      <organization>Orange</organization>
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>stephane.litkowski@orange.com</email>
        <email>slitkows.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="R" surname="Shakir" fullname="Rob Shakir">
      <organization>Google</organization>
      <organization showOnFrontPage="true">Google</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>rjs@rob.sh</email>
        <email>robjs@google.com</email>
      </address>
    </author>
    <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
      <organization></organization>
      <organization showOnFrontPage="true">Apstra, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>jefftant@gmail.com</email>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2018" /> month="12" year="2019"/>
    <area>Routing</area>
    <workgroup>Network Working Group</workgroup>
    <abstract>

<t>
    <keyword>Flow-aware load balancing</keyword>
    <keyword>ECMP</keyword>
    <keyword>equal-cost multipath</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">
  Segment Routing (SR) leverages the source routing source-routing paradigm.  A node steers a
  packet through an ordered list of instructions, called segments. Segment
  Routing can be applied to the Multi Protocol Multiprotocol Label Switching (MPLS) data
  plane.  Entropy label (EL) is a technique labels (ELs) are used in MPLS to improve load-balancing.
  This document examines and describes how ELs are to be applied to Segment
  Routing MPLS.
</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of
            RFC 7841.
        </t>
        <t pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8662" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-abbreviations-and-terminolo">Abbreviations and Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-use-case-requiring-multipat">Use Case Requiring Multipath Load-Balancing</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-entropy-readable-label-dept">Entropy Readable Label Depth</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-maximum-sid-depth">Maximum SID Depth</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lsp-stitching-using-the-bin">LSP Stitching Using the Binding SID</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-insertion-of-entropy-labels">Insertion of Entropy Labels for SPRING Path</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-1-the-ingress-node-">Example 1: The Ingress Node Has a Sufficient MSD</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.1.2.2.1"><xref derivedContent="7.1.2" format="counter" sectionFormat="of" target="section-7.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-example-2-the-ingress-node-">Example 2: The Ingress Node Does Not Have a Sufficient MSD</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-considerations-for-the-plac">Considerations for the Placement of Entropy Labels</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-erld-value">ERLD Value</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.2">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.2.1"><xref derivedContent="7.2.2" format="counter" sectionFormat="of" target="section-7.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-segment-type">Segment Type</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.3">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.3.1"><xref derivedContent="7.2.3" format="counter" sectionFormat="of" target="section-7.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-maximizing-number-of-lsrs-t">Maximizing Number of LSRs That Will Load-Balance</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.4">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.4.1"><xref derivedContent="7.2.4" format="counter" sectionFormat="of" target="section-7.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-preference-for-a-part-of-th">Preference for a Part of the Path</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.5">
                    <t keepWithNext="true" pn="section-toc.1-1.7.2.2.2.5.1"><xref derivedContent="7.2.5" format="counter" sectionFormat="of" target="section-7.2.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-combining-criteria">Combining Criteria</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a-simple-example-algorithm">A Simple Example Algorithm</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-considerations">Deployment Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t keepWithNext="true" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-options-considered">Options Considered</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-single-el-at-the-bottom-of-">Single EL at the Bottom of the Stack</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-an-el-per-segment-in-the-st">An EL per Segment in the Stack</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.3">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.3.1"><xref derivedContent="10.3" format="counter" sectionFormat="of" target="section-10.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a-reusable-el-for-a-stack-o">A Reusable EL for a Stack of Tunnels</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.4">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.4.1"><xref derivedContent="10.4" format="counter" sectionFormat="of" target="section-10.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-el-at-top-of-stack">EL at Top of Stack</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.5">
                <t keepWithNext="true" pn="section-toc.1-1.10.2.5.1"><xref derivedContent="10.5" format="counter" sectionFormat="of" target="section-10.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-els-at-readable-label-stack">ELs at Readable Label Stack Depths</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t keepWithNext="true" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t keepWithNext="true" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t keepWithNext="true" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t keepWithNext="true" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t keepWithNext="true" pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.15">
            <t keepWithNext="true" pn="section-toc.1-1.15.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t keepWithNext="true" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction" toc="default">
   <t> toc="include" numbered="true" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">
   Segment Routing <xref target="I-D.ietf-spring-segment-routing"/> target="RFC8402" format="default" sectionFormat="of" derivedContent="RFC8402"/> is based on source routed
   source-routed tunnels to steer a packet along a particular path. This path
   is encoded as an ordered list of segments.  When applied to the MPLS dataplane data
   plane <xref target="I-D.ietf-spring-segment-routing-mpls"/>, target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/>, each segment is an LSP
   (Label Switched Path) with an associated MPLS label value.  Hence, label
   stacking is used to represent the ordered list of segments segments, and the label
   stack associated with an SR tunnel can be seen as nested LSPs (LSP
   hierarchy) in the MPLS architecture.
      </t>
	<t>
      <t pn="section-1-2">
	Using label stacking to encode the list of segments has implications on the label stack depth.
      </t>

<t>
      <t pn="section-1-3">
   Traffic load-balancing over ECMP (Equal Cost Multi Path) (Equal-Cost Multipath) or LAGs (Link
   Aggregation Groups) is usually based on a hashing function. The local node which
   that performs the load-balancing is required to read some header fields in
   the incoming packets and then computes compute a hash based on those fields. The
   result of the hash is finally mapped to a list of outgoing nexthops. next hops.  The
   hashing technique is required to perform a per-flow load-balancing and thus
   thus, prevents packet misordering. For IP traffic, the usual fields that
   are hashed are the source address, the destination address, the protocol
   type, and, if provided by the upper layer, the source port and destination
   port.
</t>
<t>
      <t pn="section-1-4">
   The MPLS architecture brings some challenges when an LSR (Label Switching
   Router) tries to look up at header fields. An LSR (Label Switching Router) needs be able to look up
   at header fields that are beyond the MPLS label stack while the MPLS header
   does not provide any information about the upper layer upper-layer protocol.  An LSR
   must perform a deeper inspection compared to an ingress router router, which could
   be challenging for some hardware.  Entropy label (EL) labels (ELs) <xref target="RFC6790"/> is a technique target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/> are used in the MPLS data
   plane to provide entropy for load-balancing.  The idea behind the entropy
   label is that the ingress router computes a hash based on several fields
   from a given packet and places the result in an additional label, label named
   "entropy label".  Then, this entropy label can be used as part of the hash
   keys used by an LSR. Using the entropy label as part of the hash keys
   reduces the need for deep packet inspection in the LSR while keeping a good
   level of entropy in the load-balancing.  When the entropy label is used,
   the keys used in the hashing functions are still a local configuration matter
   matter, and an LSR may use solely the entropy label or a combination of
   multiple fields from the incoming packet.
      </t>
   <t>
      <t pn="section-1-5">
   When using LSP
   hierarchies, there are implications on how <xref target="RFC6790"/> target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/> should be
   applied.  The current document addresses the case where a hierarchy
   is created at a single LSR as required by Segment Routing.
</t>
<t>
      <t pn="section-1-6">
   A use-case use case requiring load-balancing with SR is given in <xref target="usecase"/>. target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>.  A recommended solution is
   described in <xref target="solution"/> target="solution" format="default" sectionFormat="of" derivedContent="Section 7"/> keeping in consideration the limitations of
   implementations when applying <xref target="RFC6790"/> target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/> to deeper label stacks.
   Options that were considered to arrive at the recommended solution
   are documented for historical purposes in <xref target="other-options"/>. target="other-options" format="default" sectionFormat="of" derivedContent="Section 10"/>.

</t>
      <section title="Requirements Language" toc="default">
        <t> toc="include" numbered="true" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-requirements-language">Requirements Language</name>
        <t pn="section-1.1-1">
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in
   BCP 14 BCP 14 <xref target="RFC2119"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174"/> target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
        </t>
      </section>
    </section>
    <section title="Abbreviations and Terminology" toc="default">
      <t>
        <list style="hanging">
		  <t>Adj-SID - Adjacency toc="include" numbered="true" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-abbreviations-and-terminolo">Abbreviations and Terminology</name>
      <dl newline="false" spacing="normal" indent="10" pn="section-2-1">
        <dt pn="section-2-1.1">Adj-SID</dt>
        <dd pn="section-2-1.2">Adjacency Segment Identifier</t>
          <t>ECMP - Equal Cost Multi Path</t>
		  <t>EL - Entropy Label</t>
          <t>ELI - Entropy Identifier</dd>
        <dt pn="section-2-1.3">ECMP</dt>
        <dd pn="section-2-1.4">Equal-Cost Multipath</dd>
        <dt pn="section-2-1.5">EL</dt>
        <dd pn="section-2-1.6">Entropy Label</dd>
        <dt pn="section-2-1.7">ELI</dt>
        <dd pn="section-2-1.8">Entropy Label Indicator</t>
		  <t>ELC - Entropy Indicator</dd>
        <dt pn="section-2-1.9">ELC</dt>
        <dd pn="section-2-1.10">Entropy Label Capability</t>
		  <t>ERLD - Entropy Capability</dd>
        <dt pn="section-2-1.11">ERLD</dt>
        <dd pn="section-2-1.12">Entropy Readable Label Depth</t>
		  <t>FEC - Forwarding Equivalent Class</t>
		  <t>LAG - Link Depth</dd>
        <dt pn="section-2-1.13">FEC</dt>
        <dd pn="section-2-1.14">Forwarding Equivalence Class</dd>
        <dt pn="section-2-1.15">LAG</dt>
        <dd pn="section-2-1.16">Link Aggregation Group</t>
		  <t>LSP - Label Group</dd>
        <dt pn="section-2-1.17">LSP</dt>
        <dd pn="section-2-1.18">Label Switched Path</t>
		  <t>LSR - Label Path</dd>
        <dt pn="section-2-1.19">LSR</dt>
        <dd pn="section-2-1.20">Label Switching Router</t>
		  <t>MPLS - Multiprotocol Router</dd>
        <dt pn="section-2-1.21">MPLS</dt>
        <dd pn="section-2-1.22">Multiprotocol Label Switching</t>
		  <t>MSD - Maximum Switching</dd>
        <dt pn="section-2-1.23">MSD</dt>
        <dd pn="section-2-1.24">Maximum SID Depth</t>
		  <t>Node-SID - Node Depth</dd>
        <dt pn="section-2-1.25">Node SID</dt>
        <dd pn="section-2-1.26">Node Segment Identifier</t>
		  <t>OAM - Operation, Administration and Maintenance</t>
		  <t>RLD - Readable Identifier</dd>
        <dt pn="section-2-1.27">OAM</dt>
        <dd pn="section-2-1.28">Operations, Administration, and Maintenance</dd>
        <dt pn="section-2-1.29">RLD</dt>
        <dd pn="section-2-1.30">Readable Label Depth</t>
		  <t>SID - Segment Identifier</t>
		  <t>SPT - Shortest Depth</dd>
        <dt pn="section-2-1.31">SID</dt>
        <dd pn="section-2-1.32">Segment Identifier</dd>
        <dt pn="section-2-1.33">SPT</dt>
        <dd pn="section-2-1.34">Shortest Path Tree</t>
		  <t>SR - Segment Routing</t>
		  <t>SRGB - Segment Tree</dd>
        <dt pn="section-2-1.35">SR</dt>
        <dd pn="section-2-1.36">Segment Routing</dd>
        <dt pn="section-2-1.37">SRGB</dt>
        <dd pn="section-2-1.38">Segment Routing Global Block</t>
		  <t>VPN - Virtual Block</dd>
        <dt pn="section-2-1.39">VPN</dt>
        <dd pn="section-2-1.40">Virtual Private Network</t>
        </list>
      </t> Network</dd>
      </dl>
    </section>
    <section anchor="usecase" title="Use-case requiring multipath load-balancing" toc="default">
	<figure title="Figure 1: toc="include" numbered="true" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-use-case-requiring-multipat">Use Case Requiring Multipath Load-Balancing</name>
      <t pn="section-3-1">
Traffic engineering use-case">
	<artwork>
                         +------+
                         |      |
                 +-------|  P3  |-----+
                 | +-----|      |---+ |
               L3| |L4   +------+ L1| |L2     +----+
                 | |                | |    +--| P4 |--+
   +-----+     +-----+            +-----+  |  +----+  |  +-----+
   |  S  |-----| P1  |------------| P2  |--+          +--|  D  |
   |     |     |     |            |     |--+          +--|     |
   +-----+     +-----+            +-----+  |  +----+  |  +-----+
                                           +--| P5 |--+
                                              +----+
       S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs,
                             L1,L2,L3,L4=Links

	</artwork>
	</figure>
	<t>
	Traffic-engineering is one of the applications of MPLS and is also a
requirement for Segment Routing <xref target="RFC7855"/>. target="RFC7855" format="default" sectionFormat="of" derivedContent="RFC7855"/>.  Consider the
topology shown in Figure 1. <xref target="fig_TE_use_case" format="default" sectionFormat="of" derivedContent="Figure 1"/>.  The LSR S requires data to be sent to LSR D along
a traffic-engineered path that goes over the link L1.  Good load-balancing is
also required across equal cost equal-cost paths (including parallel links).  To steer
traffic along a path that crosses link L1, the label stack that LSR S creates
consists of a label to the Node-SID Node SID of LSR P3, P3 stacked over the label for the
Adj-SID (Adjacency Segment Identifier) of link L1 and that in turn is stacked
over the label to the Node-SID Node SID of LSR D.  For
   simplicity simplicity, lets assume that all
LSRs use the same label space for Segment Routing (as a reminder, it is called
the SRGB, Segment Routing Global Block).  Let L_N-Px denote the label to be
used to reach the Node-SID Node SID of LSR Px.  Let L_A-Ln denote the label used for
the Adj-SID for link Ln.  In our example, the LSR S must use the label stack
&lt;L_N-P3, L_A-L1, L_N-D&gt;. However, to achieve a good load-balancing over
the equal cost equal-cost paths P2-P4-D,
   P2-P5-D P2-P5-D, and the parallel links L3 and L4, a
mechanism such as entropy labels <xref target="RFC6790"/> target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/> should be adapted
for Segment Routing.  Indeed, the SPRING Source Packet Routing in Networking (SPRING)
architecture with the MPLS dataplane (<xref target="I-D.ietf-spring-segment-routing-mpls"/>) data plane <xref target="RFC8660" format="default" sectionFormat="of" derivedContent="RFC8660"/> uses nested
MPLS LSPs composing the source routed source-routed label stack.
      </t>
   <t>
      <figure anchor="fig_TE_use_case" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-traffic-engineering-use-cas">Traffic-Engineering Use Case</name>
        <artwork name="" type="" align="left" alt="" pn="section-3-2.1">
                      +------+
                      |      |
              +-------|  P3  |-----+
              | +-----|      |---+ |
            L3| |L4   +------+ L1| |L2     +----+
              | |                | |    +--| P4 |--+
+-----+     +-----+            +-----+  |  +----+  |  +-----+
|  S  |-----| P1  |------------| P2  |--+          +--|  D  |
|     |     |     |            |     |--+          +--|     |
+-----+     +-----+            +-----+  |  +----+  |  +-----+
                                        +--| P5 |--+
                                           +----+
    Key:
        S = Source LSR
        D = Destination LSR
        P1, P2, P3, P4, P5 = Transit LSRs
        L1, L2, L3, L4 = Links
</artwork>
      </figure>
      <t pn="section-3-3">
   An MPLS node may have limitations in the number of labels it can push. It may also have a limitation in the number of labels it can inspect when looking for hash keys during load-balancing.
   While the entropy label is normally inserted at the bottom of the transport tunnel, this may prevent an LSR from taking into account the EL in its load-balancing function if the EL is too deep in the stack.
   In a Segment Routing environment, it is important to define the considerations that needs need to be taken into account when inserting an EL.
   Multiple ways to apply entropy labels were considered and are
   documented in <xref target="other-options"/> target="other-options" format="default" sectionFormat="of" derivedContent="Section 10"/> along with their trade-offs.  A recommended
   solution is described in <xref target="solution"/>. target="solution" format="default" sectionFormat="of" derivedContent="Section 7"/>.
</t>
    </section>
    <section anchor="erld_definition" title="Entropy numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-entropy-readable-label-dept">Entropy Readable Label Depth">
   <t> Depth</name>
      <t pn="section-4-1">
   The Entropy Readable Label Depth (ERLD) is defined as the number of labels a router can both:
   <list style="letters">
   <t>Read
      </t>
      <ol spacing="normal" type="a" start="1" pn="section-4-2">
        <li pn="section-4-2.1" derivedCounter="a.">Read in an MPLS packet received on its incoming interface(s) (starting from the top of the stack).</t>
   <t>Use stack).</li>
        <li pn="section-4-2.2" derivedCounter="b.">Use in its load-balancing function.</t>
   </list>
   </t>
   <t>The function.</li>
      </ol>
      <t pn="section-4-3">The ERLD means that the router will perform load-balancing using the EL label if the EL is placed within the first ERLD labels.</t>
   <t>A
      <t pn="section-4-4">A router capable of reading N labels but not using an EL located within those N labels MUST <bcp14>MUST</bcp14> consider its ERLD to be 0.</t>
   <t>
      <t pn="section-4-5">
   In a distributed switching architecture, each linecard line card may have a
   different capability in terms of ERLD. For simplicity, an implementation MAY
   <bcp14>MAY</bcp14> use the minimum ERLD of all linecards line cards as the ERLD value for the system.
      </t>
   <t>There
      <t pn="section-4-6">There may also be a case where a router has a fast switching path
   (handled by an ASIC Application-Specific Integrated Circuit, or ASIC, or network processor) and a slow switching path (handled by a CPU) with a different ERLD for each switching path. Again, for simplicity's sake, an implementation MAY <bcp14>MAY</bcp14> use the minimum ERLD as the ERLD value for the system.</t>
   <t>The
      <t pn="section-4-7">The drawback of using a single ERLD for a system lower than the capability of one or more specific component components is that it may increase the number of ELI/ELs inserted. This leads to an increase of the label stack size and may have an impact on the capability of the ingress node to push this label stack.</t>
   <t>Examples:</t>
      <t pn="section-4-8">Examples:</t>
      <figure title="Figure 2: Label stacks anchor="fig_label_stacks" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-label-stacks-with-eli-el">Label Stacks with ELI/EL">
   <artwork> ELI/EL</name>
        <artwork name="" type="" align="left" alt="" pn="section-4-9.1">
                                                    | Payload  |
                                                    +----------+
                                       | Payload  | |    EL    | P7
                                       +----------+ +----------+
                          | Payload  | |    EL    | |    ELI   |
                          +----------+ +----------+ +----------+
             | Payload  | |   EL     | |    ELI   | | Label 50 |
             +----------+ +----------+ +----------+ +----------+
|  Payload | |     EL   | |   ELI    | | Label 40 | | Label 40 |
+----------+ +----------+ +----------+ +----------+ +----------+
|     EL   | |    ELI   | | Label 30 | | Label 30 | | Label 30 |
+----------+ +----------+ +----------+ +----------+ +----------+
|    ELI   | | Label 20 | | Label 20 | | Label 20 | | Label 20 |
+----------+ +----------+ +----------+ +----------+ +----------+
| Label 16 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | P1
+----------+ +----------+ +----------+ +----------+ +----------+
  Packet 1     Packet 2     Packet 3     Packet 4     Packet 5
</artwork>
      </figure>
   <t>
      <t pn="section-4-10">
   In Figure 2, <xref target="fig_label_stacks" format="default" sectionFormat="of" derivedContent="Figure 2"/>, we consider the displayed packets received on a router interface. We consider also a single ERLD value for the router.
   <list style="symbols">
   <t>If
      </t>
      <ul spacing="normal" bare="false" empty="false" pn="section-4-11">
        <li pn="section-4-11.1">If the router has an ERLD of 3, it will be able to load-balance Packet 1 displayed in Figure 2 <xref target="fig_label_stacks" format="default" sectionFormat="of" derivedContent="Figure 2"/> using the EL as part of the load-balancing keys. The ERLD value of 3 means that the router can read and take into account the entropy label for load-balancing if it is placed between position 1 (top of the MPLS label stack) and position 3.</t>
   <t>If 3.</li>
        <li pn="section-4-11.2">If the router has an ERLD of 5, it will be able to load-balance Packets
   1 to 3 in Figure 2 <xref target="fig_label_stacks" format="default" sectionFormat="of" derivedContent="Figure 2"/> using the EL as part of the load-balancing keys. Packets
   4 and 5 have the EL placed at a position greater than 5, so the router is
   not able to read it and use it as part of the load-balancing keys.</t>
   <t>If keys.</li>
        <li pn="section-4-11.3">If the router has an ERLD of 10, it will be able to load-balance all the packets displayed in Figure 2 <xref target="fig_label_stacks" format="default" sectionFormat="of" derivedContent="Figure 2"/> using the EL as part of the load-balancing keys.</t>
   </list>
   </t>

   <t>To keys.</li>
      </ul>
      <t pn="section-4-12">To allow an efficient load-balancing based on entropy labels, a router running SPRING SHOULD <bcp14>SHOULD</bcp14> advertise its ERLD (or ERLDs), so all the other SPRING routers in the network are aware of its capability. How this advertisement is done is outside the scope of this document (see <xref target="erld"/> target="erld" format="default" sectionFormat="of" derivedContent="Section 7.2.1"/> for potential approaches).
      </t>
   <t>
      <t pn="section-4-13">
   To advertise an ERLD value, a SPRING router:
   <list style="symbols">
   <t>MUST
      </t>
      <ul spacing="normal" bare="false" empty="false" pn="section-4-14">
        <li pn="section-4-14.1">
          <bcp14>MUST</bcp14> be entropy label capable and, as a consequence, MUST <bcp14>MUST</bcp14> apply the dataplane data-plane procedures defined in <xref target="RFC6790"/>.</t>
   <t>MUST target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>.</li>
        <li pn="section-4-14.2">
          <bcp14>MUST</bcp14> be able to read an ELI/EL ELI/EL, which is located within its ERLD value.</t>
   <t>MUST value.</li>
        <li pn="section-4-14.3">
          <bcp14>MUST</bcp14> take into account an EL within the first ERLD labels in its load-balancing function.</t>
   </list>
   </t> function.</li>
      </ul>
    </section>
    <section anchor="msd" title="Maximum numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-maximum-sid-depth">Maximum SID Depth">
   <t> Depth</name>
      <t pn="section-5-1">
   The Maximum SID Depth defines the maximum number of labels that a
   particular node can impose on a packet. This can include any kind of labels
   (service, entropy, transport...). transport, etc.).  In an MPLS network, the MSD is a
   limit of the head-end of an SR tunnel or a Binding-SID Binding SID anchor node that
   performs imposition of additional labels on an existing label stack.
      </t>
   <t>
      <t pn="section-5-2">
   Depending on the number of MPLS operations (POP, SWAP...) SWAP, etc.) to be performed before the PUSH, the MSD can vary due to hardware or software limitations.
   As for the ERLD, different MSD limits can exist within a single node based
   on the linecard line-card types used in a distributed switching system. Thus, the MSD is a per link and/or per node per-node property.
      </t>
   <t>
      <t pn="section-5-3">
   An external controller can be used to program a label stack on a particular
   node. This node SHOULD <bcp14>SHOULD</bcp14> advertise its MSD to the controller
   in order to let the controller know the maximum label stack depth of the
   path computed that is supported on the head-end.

   How this advertisement is done is outside the scope of this document
   document. (<xref target="I-D.ietf-isis-segment-routing-msd"/>, target="RFC8476" format="default" sectionFormat="of" derivedContent="RFC8476"/>, <xref target="I-D.ietf-isis-segment-routing-msd"/> target="RFC8491" format="default" sectionFormat="of" derivedContent="RFC8491"/>, and <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/> target="I-D.ietf-idr-bgp-ls-segment-routing-msd" format="default" sectionFormat="of" derivedContent="MSD-BGP"/> provide
   examples of advertisement of MSD). the MSD.)  As the controller does not have the
   knowledge of the entire label stack to be pushed by the node, in addition
   to the MSD value, the node SHOULD <bcp14>SHOULD</bcp14> advertise the type of the
   MSD.  For instance, the MSD value can represent the limit for pushing
   transport labels only while in reality the node can push an additional
   service label. As another example, the MSD value can represent the full
   limit of the node including all label types (transport, service, entropy...). entropy,
   etc.).  This gives the ability for the controller to program a label stack
   while leaving room for the local node to add more labels (e.g., service, entropy,...)
   entropy, etc.) without reaching the hardware/software limit.  If the node
   does not provide the meaning of the MSD value, the controller could program
   an LSP using a number of labels equal to the full limit of the node. When
   receiving this label stack from the controller, the ingress node may not be
   able to add any service (L2VPN, L3VPN, EVPN...) EVPN, etc.) label on top of this
   label stack.  The consequence could be for the ingress node to drop service
   packets that should have been forwarded over the LSP.
      </t>
      <figure title="Figure 3">
   <artwork> anchor="fig_packet" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-topology-illustrating-label">Topology Illustrating Label Stack Reduction</name>
        <artwork name="" type="" align="left" alt="" pn="section-5-4.1">
              P7 ---- P8 ---- P9
            /                   \
    PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2
                                        |  \            |
---->
----&gt;                                  P10  \           |
IP Pkt                                  |    \          |
                                       P11 --- P12 --- P13
                                           100    10000
</artwork>
      </figure>
   <t>
      <t pn="section-5-5">
   In Figure 3, <xref target="fig_packet" format="default" sectionFormat="of" derivedContent="Figure 3"/>, an IP packet comes into the MPLS network at PE1. All metrics
   are considered equal to 1 except P12-P13 P12-P13, which is 10000 10000, and P11-P12 P11-P12,
   which is 100.  PE1 wants to steer the traffic using a SPRING path to PE2
   along PE1->P1->P7->P8->P9->P4->P5->P10->P11->P12->P13->PE2. PE1 -&gt; P1 -&gt; P7 -&gt; P8 -&gt; P9 -&gt; P4 -&gt; P5 -&gt; P10 -&gt; P11 -&gt; P12 -&gt; P13
   -&gt; PE2.  By using Adj-SIDs only, PE1 (acting as an ingress LSR, also known
   as an I-LSR) will be required to push 10 labels on the IP packet received
   and thus thus, requires an MSD of 10.  If the IP packet should be carried over
   an MPLS service like a regular layer 3 VPN, an additional service label
   should be imposed, imposed requiring an MSD of 11 for PE1.  In addition, if PE1
   wants to insert an ELI/EL for load-balancing purpose, purposes, PE1 will need to
   push 13 labels on the IP packet requiring an MSD of 13.
      </t>
   <t>
      <t pn="section-5-6">
   In the SPRING architecture, Node-SIDs Node SIDs or Binding-SIDs Binding SIDs can be used to reduce the label stack size. As an example, to steer the traffic on the same path as before, PE1 could use the following label stack: &lt;Node_P9, Node_P5, Binding_P5, Node_PE2&gt;.
   In this example example, we consider a combination of Node-SIDs Node SIDs and a Binding-SID Binding SID
   advertised by P5 that will stitch the traffic along the path P10->P11->P12->P13. P10 -&gt; P11
   -&gt; P12 -&gt; P13. The instruction associated with the Binding-SID Binding SID at P5 is thus to swap Binding_P5 to Adj_P12-P13 and then push &lt;Adj_P11-P12, Node_P11&gt;.
   P5 acts as a stitching node that pushes additional labels on an existing label stack, stack; P5's MSD needs also to be taken into account and may limit the number of labels that can be imposed.
      </t>
    </section>
    <section anchor="stitching" title="LSP stitching using numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-lsp-stitching-using-the-bin">LSP Stitching Using the Binding-SID">
   <t> Binding SID</name>
      <t pn="section-6-1">
   The Binding-SID Binding SID allows binding a segment identifier to an existing LSP. As
   examples, the Binding-SID Binding SID can represent an RSVP-TE tunnel, an LDP path
   (through the mapping server advertisement), Mapping Server Advertisement), or a SPRING path.  Each
   tail-end router of an MPLS LSP associated with a Binding-SID Binding SID has its own
   entropy label capability. The entropy label capability of the associated
   LSP is advertised in the control plane control-plane protocol used to signal the LSP.
      </t>
	<t>
      <t pn="section-6-2">
In Figure 4, <xref target="fig_stitching_example" format="default" sectionFormat="of" derivedContent="Figure 4"/>, we consider that:
	<list style="symbols">
	<t>P6,
</t>
      <ul spacing="normal" bare="false" empty="false" pn="section-6-3">
        <li pn="section-6-3.1">P6, PE2, P10, P11, P12, and P13 are pure LDP routers.</t>
	<t>PE1, routers.</li>
        <li pn="section-6-3.2">PE1, P1, P2, P3, P4, P7, P8, and P9 are pure SPRING routers.</t>
	<t>P5 routers.</li>
        <li pn="section-6-3.3">P5 is running SPRING and LDP.</t>
	<t>P5 LDP.</li>
        <li pn="section-6-3.4">P5 acts as a mapping server Mapping Server and advertises Prefix SIDs Prefix-SIDs for the LDP FECs: an index value of 20 is used for PE2.</t>
	<t>All PE2.</li>
        <li pn="section-6-3.5">All SPRING routers use an SRGB of [1000, 1999].</t>
	<t>P6 1999].</li>
        <li pn="section-6-3.6">P6 advertises label 20 for the PE2 FEC.</t>
	<t>Traffic FEC.</li>
        <li pn="section-6-3.7">Traffic from PE1 to PE2 uses the shortest path.</t>
	</list>
	</t>
	<figure>
	<artwork> path.</li>
      </ul>
      <figure anchor="fig_stitching_example" align="left" suppress-title="false" pn="figure-4">
        <name slugifiedName="name-example-illustrating-need-f">Example Illustrating Need for ELC Propagation</name>
        <artwork name="" type="" align="left" alt="" pn="section-6-4.1">
        PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2

    -->
    --&gt;    +----+                   +----+   +----+  +----+
  IP Pkt   | IP |                   | IP |   | IP |  | IP |
           +----+                   +----+   +----+  +----+
           |1020|                   |1020|   | 20 |
           +----+                   +----+   +----+
                                    SPRING    LDP
</artwork>
      </figure>
	<t>In
      <t pn="section-6-5">In terms of packet forwarding, by learning the mapping-server advertisement Mapping Server Advertisement from P5, PE1 imposes a label 1020 to an IP packet destined to PE2.
	SPRING routers along the shortest path to PE2 will switch the traffic
	until it reaches P5. P5 will perform the LSP stitching by swapping the
	SPRING label 1020 to the LDP label 20 advertised by the nexthop next hop P6.
	P6 will finally forward the packet using the LDP label towards PE2.</t>
	<t>
      <t pn="section-6-6">
	PE1 cannot push an ELI/EL for the Binding-SID Binding SID without knowing that the tail-end
	tail end of the LSP associated with the binding (PE2) is entropy label capable.
      </t>
	<t>
      <t pn="section-6-7">
	To accommodate the mix of signaling protocols involved during the stitching, the entropy label capability SHOULD <bcp14>SHOULD</bcp14> be propagated between the signaling domains.
	Each Binding-SID SHOULD Binding SID <bcp14>SHOULD</bcp14> have its own entropy label capability that MUST <bcp14>MUST</bcp14> be inherited from the entropy label capability of the associated LSP.
	If the router advertising the Binding-SID Binding SID does not know the ELC state
	of the target FEC, it MUST NOT <bcp14>MUST NOT</bcp14> set the ELC for the Binding-SID.
	Binding SID.
	An ingress node MUST NOT <bcp14>MUST NOT</bcp14> push an ELI/EL associated with
	a Binding-SID Binding SID unless this Binding-SID Binding SID has the entropy label capability.
	How the entropy label capability is advertised for a Binding-SID Binding SID is outside the scope of this document (see <xref target="erld"/> target="erld" format="default" sectionFormat="of" derivedContent="Section 7.2.1"/> for potential approaches).
      </t>
	<t>
      <t pn="section-6-8">
	In our example, if PE2 is LDP entropy label capable, it will add the
	entropy label capability in its LDP advertisement. When P5 receives
	the FEC/label binding for PE2, it learns about the ELC and can set the
	ELC in the mapping server advertisement. Thus Mapping Server Advertisement. Thus, PE1 learns about the
	ELC of PE2 and may push an ELI/EL associated with the Binding-SID. Binding SID.
      </t>
	<t>
      <t pn="section-6-9">
	The proposed solution only works if the SPRING router advertising the Binding-SID
	Binding SID is also performing the dataplane data-plane LSP stitching.
	In our example, if the mapping server Mapping Server function is hosted on P8 instead
	of P5, P8 does not know about the ELC state of PE2's LDP FEC. As a
	consequence, it does not set the ELC for the associated Binding-SID. Binding SID.
      </t>
    </section>
    <section anchor="solution" title="Insertion toc="include" numbered="true" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-insertion-of-entropy-labels">Insertion of entropy labels Entropy Labels for SPRING path" toc="default"> Path</name>
      <section anchor="overview" title="Overview">
	<t> numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-overview">Overview</name>
        <t pn="section-7.1-1">
	The solution described in this section follows the dataplane data-plane processing defined in <xref target="RFC6790"/>. target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>. Within a SPRING path, a node may be ingress, egress, transit (regarding the entropy label processing described in <xref target="RFC6790"/>), target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>), or it can be any combination of those.
	For example:
		<list style="symbols">
		<t>The
        </t>
        <ul spacing="normal" bare="false" empty="false" pn="section-7.1-2">
          <li pn="section-7.1-2.1">The ingress node of a SPRING domain can be an ingress node from an entropy label perspective.</t>
		<t>Any perspective.</li>
          <li pn="section-7.1-2.2">Any LSR terminating a segment of the SPRING path is an egress node (because it terminates the segment) but can also be a transit node if the SPRING path is not terminated because there is a subsequent SPRING MPLS label in the stack.</t>
		<t>Any stack.</li>
          <li pn="section-7.1-2.3">Any LSR processing a Binding-SID Binding SID may be a transit node and an
	  ingress node (because it may push additional labels when processing
	  the Binding-SID).</t>
		</list>
	</t>
	<t> Binding SID).</li>
        </ul>
        <t pn="section-7.1-3">
	As described earlier, an LSR may have a limitation (the ERLD) on the depth of the label stack that it
   can read and process in order to do multipath load-balancing based on entropy labels.</t>
   <t>If
        <t pn="section-7.1-4">If an EL does not occur within the ERLD of an
   LSR in the label stack of an MPLS packet that it receives, then it
   would lead to poor load-balancing at that LSR.  Hence  Hence, an ELI/EL pair
   must be within the ERLD of the LSR in order for the LSR to use the EL
   during load-balancing.
        </t>
	<t>
        <t pn="section-7.1-5">
   Adding a single ELI/EL pair for the entire SPRING path can also lead
   to poor load-balancing as well because the ELI/EL may not occur within
   the ERLD of some LSR on the path (if too deep) or may not be present
   in the stack when it reaches some LSRs (if it is too shallow).
        </t>
	<t>
        <t pn="section-7.1-6">
    In order for the EL to occur within the ERLD of LSRs along the path
   corresponding to a SPRING label stack, multiple &lt;ELI, EL&gt; pairs MAY <bcp14>MAY</bcp14> be
   inserted in this label stack.
        </t>
   <t>
        <t pn="section-7.1-7">
   The insertion of an ELI/EL MUST <bcp14>MUST</bcp14> occur only with a SPRING
   label advertised by an LSR that advertised an ERLD (the LSR is entropy
   label capable) or with a SPRING label associated with a Binding-SID Binding SID that has the ELC set.
        </t>
   <t>
        <t pn="section-7.1-8">
   The ELs among multiple &lt;ELI, EL&gt; pairs inserted in the
   stack MAY <bcp14>MAY</bcp14> be the same or different. The LSR that inserts &lt;ELI, EL&gt; pairs
   can have limitations on the number of such pairs that it can insert
   and also the depth at which it can insert them.  If, due to
   limitations, the inserted ELs are at positions such that an LSR along
   the path receives an MPLS packet without an EL in the label stack
   within that LSR's ERLD, then the load-balancing performed by that LSR
   would be poor. An implementation MAY <bcp14>MAY</bcp14> consider multiple criteria when inserting &lt;ELI, EL&gt; pairs.
        </t>
        <section anchor="ex1" title="Example 1 where the ingress node has numbered="true" toc="include" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-example-1-the-ingress-node-">Example 1: The Ingress Node Has a sufficient MSD"> Sufficient MSD</name>
          <figure title="Figure 5">
	<artwork> anchor="fig_ex1" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-accommodating-msd-limitatio">Accommodating MSD Limitations</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.1.1-1.1">
                     ECMP          LAG           LAG
   PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2
</artwork>
          </figure>
	<t>
          <t pn="section-7.1.1-2">
	In Figure 5, <xref target="fig_ex1" format="default" sectionFormat="of" derivedContent="Figure 5"/>, PE1 wants to forward some MPLS VPN traffic over an explicit path to PE2 resulting in the following label stack to be pushed onto the received IP header: &lt;Adj_P1P2, Adj_set_P2P3, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_P6PE2, VPN_label&gt;.
PE1 is limited to push a maximum of 11 labels (MSD=11). P2, P3 P3, and P6 have an ERLD of 3 while others have an ERLD of 10.
          </t>
	<t>
          <t pn="section-7.1.1-3">
	PE1 can only add two ELI/EL pairs in the label stack due to its MSD limitation. It should insert them strategically to benefit load-balancing along the longest part of the path.
          </t>
	<t>
          <t pn="section-7.1.1-4">
	PE1 can take into account multiple parameters when inserting ELs, ELs; as examples:
	<list style="symbols">
	<t>The
          </t>
          <ul spacing="normal" bare="false" empty="false" pn="section-7.1.1-5">
            <li pn="section-7.1.1-5.1">The ERLD value advertised by transit nodes.</t>
	<t>The nodes.</li>
            <li pn="section-7.1.1-5.2">The requirement of load-balancing for a particular label value.</t>
	<t>Any value.</li>
            <li pn="section-7.1.1-5.3">Any service provider preference: favor beginning of the path or end of the path.</t>
	</list>
	</t>
	<t> path.</li>
          </ul>
          <t pn="section-7.1.1-6">
	In Figure 5, <xref target="fig_ex1" format="default" sectionFormat="of" derivedContent="Figure 5"/>, a good strategy may be to use the following stack &lt;Adj_P1P2, Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_P6PE2, ELI2, EL2, VPN_label&gt;.
The original stack requests P2 to forward based on a an L3 adjacency set adjacency-set that will require load-balancing. Therefore Therefore, it is important to ensure that P2 can load-balance correctly.
As P2 has a limited ERLD of 3, an ELI/EL must be inserted just after the label that P2 will use to forward.
On the path to PE2, P3 has also a limited ERLD, but P3 will forward based on a regular adjacency segment that may not require load-balancing.
Therefore
Therefore, it does not seem important to ensure that P3 can do load-balancing despite its limited ERLD.
The next nodes along the forwarding path have a high ERLD that does not cause
any issue, except P6. Moreover, P6 is using some LAGs to PE2 and so is
expected to load-balance.
It becomes important to insert a new ELI/EL just after the P6 forwarding label.
          </t>
	<t>
          <t pn="section-7.1.1-7">
	In the case above, the ingress node had was able to support a sufficient MSD to ensure
	end-to-end load-balancing while taking into account the path attributes.
However, there might be cases where the ingress node may not have the necessary label imposition capacity.
          </t>
        </section>
        <section anchor="ex2" title="Example 2 where the ingress node does not have numbered="true" toc="include" removeInRFC="false" pn="section-7.1.2">
          <name slugifiedName="name-example-2-the-ingress-node-">Example 2: The Ingress Node Does Not Have a sufficient MSD"> Sufficient MSD</name>
          <figure title="Figure 6">
	<artwork> anchor="fig_ex2" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-msd-considerations">MSD Considerations</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.1.2-1.1">
                   ECMP          LAG           ECMP         ECMP
 PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- P7 --- P8 --- PE2
</artwork>
          </figure>
	<t>
          <t pn="section-7.1.2-2">
	In Figure 6, <xref target="fig_ex2" format="default" sectionFormat="of" derivedContent="Figure 6"/>, PE1 wants to forward MPLS VPN traffic over an explicit path to PE2 resulting in the following label stack to be pushed onto the IP header: &lt;Adj_P1P2, Adj_set_P2P3, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_set_P6P7, Adj_P7P8; Adj_set_P8PE2, VPN_label&gt;.
PE1 is limited to push a maximum of 11 labels. P2, P3 P3, and P6 have an ERLD of 3 while others have an ERLD of 15.
          </t>
	<t>
          <t pn="section-7.1.2-3">
	Using a similar strategy as the previous case may lead to a dilemma, as PE1 can only push a single ELI/EL while we may need a minimum of three to load-balance the end-to-end path.
An optimized stack that would enable end-to-end load-balancing may be: &lt;Adj_P1P2, Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_set_P6P7, ELI2, EL2, Adj_P7P8, Adj_set_P8PE2, ELI3, EL3, VPN_label&gt;.
          </t>
	<t>
          <t pn="section-7.1.2-4">
	A decision needs to be taken to favor some part of the path for load-balancing considering that load-balancing may not work on the other parts.
A service provider may decide to place the ELI/EL after the P6 forwarding
label as it will allow P4 and P6 to load-balance. Placing the ELI/EL at the bottom of the stack is also a possibility enabling load-balancing for P4 and P8.
          </t>
        </section>
      </section>
      <section anchor="el_placement" title="Considerations numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-considerations-for-the-plac">Considerations for the placement Placement of entropy labels">
	<t> Entropy Labels</name>
        <t pn="section-7.2-1">
	The sample cases described in the previous section showed that ELI/EL placement when the maximum number of labels to be pushed is limited is not an easy decision decision, and multiple criteria may be taken into account.
        </t>
	<t>
        <t pn="section-7.2-2">
	This section describes some considerations that an implementation MAY <bcp14>MAY</bcp14> take into account when placing ELI/ELs. This list of criteria is not considered exhaustive and an implementation MAY <bcp14>MAY</bcp14> take into account additional criteria or tie-breakers tiebreakers that are not documented here.
	As the insertion of ELI/ELs is performed by the ingress node, having ingress nodes that do not use the same criteria does not cause an interoperability issue. However, from a network design and operation perspective, it is better to have all ingress routers using the same criteria.
        </t>
	<t>
        <t pn="section-7.2-3">
	An implementation SHOULD <bcp14>SHOULD</bcp14> try to maximize the possibility of load-balancing along the path by inserting an ELI/EL where multiple equal cost equal-cost paths are available and minimize the number of ELI/ELs that need to be inserted.
    In case of a trade-off, an implementation SHOULD <bcp14>SHOULD</bcp14> provide flexibility to the operator to select the criteria to be considered when placing ELI/ELs or specify a sub-objective subobjective for optimization.
        </t>
        <figure title="Figure 7">
			<artwork> anchor="fig_consid_sample" align="left" suppress-title="false" pn="figure-7">
          <name slugifiedName="name-msd-trade-offs">MSD Trade-Offs</name>
          <artwork name="" type="" align="left" alt="" pn="section-7.2-4.1">
                         2      2
   PE1 -- P1 -- P2 --P3 --- P4 --- P5 -- ... -- P8 -- P9 -- PE2
                     |             |
                     P3'--- P4'--- P5'
</artwork>
        </figure>
	<t>
	Figure 7
        <t pn="section-7.2-5"><xref target="fig_consid_sample" format="default" sectionFormat="of" derivedContent="Figure 7"/> will be used as reference in the following subsections. All
	metrics are equal to 1, 1 except P3-P4 and P4-P5 P4-P5, which have a metric 2.
	We consider the MSD of nodes to be the full limit of label imposition
	(including service labels, entropy labels labels, and transport labels).
        </t>
        <section anchor="erld" title="ERLD value">
		<t> numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-erld-value">ERLD Value</name>
          <t pn="section-7.2.1-1">
		As mentioned in <xref target="overview"/>, target="overview" format="default" sectionFormat="of" derivedContent="Section 7.1"/>, the ERLD value is an important parameter to consider when inserting an ELI/EL. If an ELI/EL does not fall within the ERLD of a node on the path, the node will not be able to load-balance the traffic efficiently.
          </t>
		<t>
          <t pn="section-7.2.1-2">
		The ERLD value can be advertised via protocols protocols, and those extensions are described in separate documents (for instance, <xref target="I-D.ietf-isis-mpls-elc"/> target="I-D.ietf-isis-mpls-elc" format="default" sectionFormat="of" derivedContent="ISIS-ELC"/> and <xref target="I-D.ietf-ospf-mpls-elc"/>). target="I-D.ietf-ospf-mpls-elc" format="default" sectionFormat="of" derivedContent="OSPF-ELC"/>).
          </t>
		<t>
          <t pn="section-7.2.1-3">
		Let's consider a path from PE1 to PE2 using the following stack pushed by PE1: &lt;Adj_P1P2, Node_P9, Adj_P9PE2, Service_label&gt;.
          </t>
		<t>
          <t pn="section-7.2.1-4">
		Using the ERLD as an input parameter can help to minimize the number of required ELI/EL pairs to be inserted.
        An ERLD value must be retrieved for each SPRING label in the label stack.
          </t>
		<t>
          <t pn="section-7.2.1-5">
		For a label bound to an adjacency segment, the ERLD is the ERLD of the node that has advertised the adjacency segment. In the example above, the ERLD associated with Adj_P1P2 would be the ERLD of router P1 P1, as P1 will perform the forwarding based on the Adj_P1P2 label.
          </t>
		<t>
          <t pn="section-7.2.1-6">
		For a label bound to a node segment, multiple strategies MAY <bcp14>MAY</bcp14> be implemented. An implementation MAY <bcp14>MAY</bcp14> try to evaluate the minimum ERLD value along the node segment path.
If an implementation cannot find the minimum ERLD along the path of the
segment or does not support the computation of the minimum ERLD, it SHOULD <bcp14>SHOULD</bcp14>
instead use the ERLD of the tail-end node. Using the ERLD of the tail-end tail end of the node segment mimics the behavior of <xref target="RFC6790"/> target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/> where the ingress takes only care of the egress of the LSP.
In the example above, if the implementation supports computation of minimum ERLD along the path, the ERLD associated with label Node_P9 would be the minimum ERLD between nodes {P2,P3,P4 ..., P8}.
If the implementation does not support the computation of minimum ERLD, it
will consider the ERLD of P9 (tail-end node of Node_P9 SID). While providing
the more optimal ELI/EL placement, evaluating the minimum ERLD increases the
complexity of ELI/EL insertion. As the path to the Node-SID Node SID may change over time, a recomputation of the minimum ERLD is required for each topology change. This recomputation may require the positions of the ELI/ELs to change.
          </t>
		<t>
          <t pn="section-7.2.1-7">
For a label bound to a binding segment, Binding Segment, if the binding segment Binding Segment describes a
path, an implementation MAY <bcp14>MAY</bcp14> also try to evaluate the minimum ERLD along this
path. If the implementation cannot find the minimum ERLD along the path of the
segment or does not support this evaluation, it SHOULD <bcp14>SHOULD</bcp14> instead use the ERLD of
the node advertising the Binding-SID. Binding SID.  As for the node segment, evaluating the
minimum ERLD adds complexity in the ELI/EL insertion process.
          </t>
        </section>
        <section anchor="sid-type" title="Segment type">
		<t> numbered="true" toc="include" removeInRFC="false" pn="section-7.2.2">
          <name slugifiedName="name-segment-type">Segment Type</name>
          <t pn="section-7.2.2-1">
		Depending on the type of segment a particular label is bound
		to, an implementation can deduce that this particular label
		will be subject to load-balancing on the path.
          </t>
          <section anchor="node-sid" title="Node-SID">
			<t> numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.2.1">
            <name slugifiedName="name-node-sid">Node SID</name>
            <t pn="section-7.2.2.1-1">
			An MPLS label bound to a Node-SID Node SID represents a path
			that may cross multiple hops.  Load-balancing may be
			needed on the node starting this path but also on any
			node along the path.
            </t>
			<t>
            <t pn="section-7.2.2.1-2">
			In Figure 7, <xref target="fig_consid_sample" format="default" sectionFormat="of" derivedContent="Figure 7"/>, let's consider a path from PE1 to PE2 using the following stack pushed by PE1: &lt;Adj_P1P2, Node_P9, Adj_P9PE2, Service_label&gt;.
            </t>
			<t>
            <t pn="section-7.2.2.1-3">
			If, for example, PE1 is limited to push 6 labels, it
			can add a single ELI/EL within the label stack.  An
			operator may want to favor a placement that would
			allow load-balancing along the Node-SID Node SID path.  In Figure 7, P3
			<xref target="fig_consid_sample" format="default" sectionFormat="of" derivedContent="Figure 7"/>,
			P3, which is along the Node-SID path Node SID path,
			requires load-balancing between two equal-cost paths.
            </t>
			<t>
            <t pn="section-7.2.2.1-4">
An implementation MAY <bcp14>MAY</bcp14> try to evaluate if load-balancing is really
   required within a node segment path. This could be done by running
   an additional SPT (Shortest Path Tree) computation and analysing analyzing of the node segment path to
   prevent a node segment that does not really require load-balancing from
   being preferred when placing ELI/ELs.  Such inspection may be time
   consuming for implementations and without a 100% guarantee, as a node
   segment path may use LAGs that are invisible to the IP
   topology.  As a simpler approach, an implementation MAY <bcp14>MAY</bcp14> consider that a label bound
   to a Node-SID Node SID will be subject to load-balancing and requires require an
   ELI/EL.
   ELI/⁠EL.
            </t>
          </section>
          <section anchor="adj-sid1" title="Adjacency-set SID">
			<t> numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.2.2">
            <name slugifiedName="name-adjacency-set-sid">Adjacency-Set SID</name>
            <t pn="section-7.2.2.2-1">
			An adjacency-set is an Adj-SID that refers to a set of
			adjacencies. When an adjacency-set segment is used
			within a label stack, an implementation can deduce
			that load-balancing is expected at the node that
			advertised this adjacency segment.  An implementation MAY
			<bcp14>MAY</bcp14> favor the insertion of an ELI/EL
			after the Adj-SID representing an adjacency-set.
            </t>
          </section>
          <section anchor="adj-sid2" title="Adjacency-SID representing numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.2.3">
            <name slugifiedName="name-adjacency-sid-representing-">Adjacency SID Representing a single Single IP link">
			<t> Link</name>
            <t pn="section-7.2.2.3-1">
			When an adjacency segment representing a single IP link is used within a label stack, an implementation can deduce that load-balancing may not be expected at the node that advertised this adjacency segment.
            </t>
			<t>
            <t pn="section-7.2.2.3-2">
			An implementation MAY <bcp14>MAY</bcp14> NOT place an ELI/EL after a regular Adj-SID in order to favor the insertion of ELI/ELs following other segments.
            </t>
			<t>
            <t pn="section-7.2.2.3-3">
			Readers should note that an adjacency segment representing a single IP link may require load-balancing. This is the case when a LAG (L2 bundle) is implemented between two IP nodes and the L2 bundle SR extensions <xref target="I-D.ietf-isis-l2bundles"/> target="RFC8668" format="default" sectionFormat="of" derivedContent="RFC8668"/> are not implemented.
			In such a case, it could be useful to insert an ELI/EL in a readable position for the LSR advertising the label associated with the adjacency segment.
			To communicate the requirement for load-balancing for
			a particular Adjacency-SID Adjacency SID to ingress nodes, a user can enforce the use of the L2 bundle SR extensions defined in <xref target="I-D.ietf-isis-l2bundles"/> target="RFC8668" format="default" sectionFormat="of" derivedContent="RFC8668"/> or can declare the single adjacency as an adjacency-set.
            </t>
          </section>
          <section anchor="adj-sid3" title="Adjacency-SID representing numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.2.4">
            <name slugifiedName="name-adjacency-sid-representing-a">Adjacency SID Representing a single link Single Link within an L2 bundle">
			<t> Bundle</name>
            <t pn="section-7.2.2.4-1">
			When the L2 bundle SR extensions <xref target="I-D.ietf-isis-l2bundles"/> target="RFC8668" format="default" sectionFormat="of" derivedContent="RFC8668"/> are used, adjacency segments may be advertised for each member of the bundle.
			In this case, an implementation can deduce that load-balancing is not expected on the LSR advertising this segment and MAY <bcp14>MAY</bcp14> NOT insert an ELI/EL after the corresponding label.
            </t>
          </section>
          <section anchor="adj-sid4" title="Adjacency-SID representing numbered="true" toc="exclude" removeInRFC="false" pn="section-7.2.2.5">
            <name slugifiedName="name-adjacency-sid-representing-an">Adjacency SID Representing an L2 bundle">
			<t> Bundle</name>
            <t pn="section-7.2.2.5-1">
			When the L2 bundle SR extensions <xref target="I-D.ietf-isis-l2bundles"/> target="RFC8668" format="default" sectionFormat="of" derivedContent="RFC8668"/> are used, an adjacency segment may be advertised to represent the bundle.
In this case, an implementation can deduce that load-balancing is expected on the LSR advertising this segment and MAY <bcp14>MAY</bcp14> insert an ELI/EL after the corresponding label.
            </t>
          </section>
        </section>
        <section title="Maximizing number numbered="true" toc="include" removeInRFC="false" pn="section-7.2.3">
          <name slugifiedName="name-maximizing-number-of-lsrs-t">Maximizing Number of LSRs that will load-balance">
		<t> That Will Load-Balance</name>
          <t pn="section-7.2.3-1">
		When placing ELI/ELs, an implementation MAY <bcp14>MAY</bcp14>
		optimize the number of LSRs that both need to load-balance
		(i.e., have
   ECMP paths) ECMPs) and that will be able to perform
		load-balancing (i.e., the EL label is within their ERLD).
          </t>
		<t>
          <t pn="section-7.2.3-2">
		Let's consider a path from PE1 to PE2 using the following
		stack pushed by PE1: &lt;Adj_P1P2, Node_P9, Adj_P9PE2,
		Service_label&gt;.  All routers have an ERLD of 10, 10 except P1
		and P2 P2, which have an ERLD of 4. PE1 is able to push 6 labels,
		so only a single ELI/EL can be added.
          </t>
		<t>
          <t pn="section-7.2.3-3">
		In the example above, adding an ELI/EL after Adj_P1P2 will
		only allow load-balancing at P1 P1, while inserting it after Adj_PE2P9,
		Adj_PE2P9 will allow load-balancing at P2,P3 P2, P3 ... P9 and maximizing
		maximize the number of LSRs that can perform load-balancing.
          </t>
        </section>
        <section title="Preference numbered="true" toc="include" removeInRFC="false" pn="section-7.2.4">
          <name slugifiedName="name-preference-for-a-part-of-th">Preference for a part Part of the path">
		<t> Path</name>
          <t pn="section-7.2.4-1">
		An implementation MAY <bcp14>MAY</bcp14> allow the user to favor a part of the end-to-end path when the number of ELI/ELs that can be pushed is not enough to cover the entire path.
As an example, a service provider may want to favor load-balancing at the
beginning of the path or at the end of the path, so the implementation favors
putting the ELI/ELs near the top or near of the bottom of the stack.
          </t>
        </section>
        <section title="Combining criteria">
		<t> numbered="true" toc="include" removeInRFC="false" pn="section-7.2.5">
          <name slugifiedName="name-combining-criteria">Combining Criteria</name>
          <t pn="section-7.2.5-1">
		An implementation MAY <bcp14>MAY</bcp14> combine multiple criteria to determine
		the best ELI/ELs placement. However, combining too many
		criteria could lead to implementation complexity and high
		resource consumption.  Each time the network topology changes,
		a new evaluation of the ELI/EL placement will be necessary for
		each impacted LSPs. LSP.
          </t>
        </section>
      </section>
    </section>
    <section anchor="algo-example" title="A simple example algorithm" toc="default">
 <t> toc="include" numbered="true" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-a-simple-example-algorithm">A Simple Example Algorithm</name>
      <t pn="section-8-1">
 A simple implementation might take into account the ERLD when placing ELI/EL
 while trying to minimize the number of ELI/ELs inserted and trying to
 maximize the number of LSRs that can load-balance.
      </t>
 <t>
      <t pn="section-8-2">
 The example algorithm is based on the following considerations:
 <list style="symbols">
 <t>An
      </t>
      <ul spacing="normal" bare="false" empty="false" pn="section-8-3">
        <li pn="section-8-3.1">An LSR that can insert a limited number of &lt;ELI, EL&gt; pairs should insert such pairs deeper in the stack.</t>
 <t>An stack.</li>
        <li pn="section-8-3.2">An LSR should try to insert &lt;ELI, EL&gt; pairs at positions to maximize the number of transit LSRs for which the EL occurs within the ERLD of those LSRs.</t>
 <t>An LSRs.</li>
        <li pn="section-8-3.3">An LSR should try to insert the minimum number of such pairs while trying to satisfy the above criteria.</t>
 </list>
 </t>
 <t> criteria.</li>
      </ul>
      <t pn="section-8-4">
 The pseudocode of the example algorithm is shown below.
      </t>
      <figure title="Figure 8: Example algorithm align="left" suppress-title="false" pn="figure-8">
        <name slugifiedName="name-example-algorithm-to-insert">Example Algorithm to insert Insert &lt;ELI, EL&gt; pairs Pairs in a label stack">
 <artwork> Label Stack</name>
        <sourcecode type="pseudocode" markers="false" pn="section-8-5.1">
   Initialize the current EL insertion point to the
     bottom-most label in the stack that is EL-capable
   while (local-node can push more &lt;ELI,EL&gt; pairs OR
             insertion point is not above label stack) {
       insert an &lt;ELI,EL&gt; pair below current insertion point
       move new insertion point up from current insertion point until
           ((last inserted EL is below the ERLD) AND (ERLD > &gt; 2)
                             AND
            (new insertion point is EL-capable))
       set current insertion point to new insertion point
   }
 </artwork>
</sourcecode>
      </figure>
 <t>
      <t pn="section-8-6">
 When this algorithm is applied to the example described in <xref target="usecase"/>, target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>,
   it will result in ELs being inserted in two positions, positions; one after the
   label L_N-D and another after L_N-P3.  Thus, the resulting label stack
   would be &lt;L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL&gt; EL&gt;.
</t>
    </section>
    <section anchor="deployment" title="Deployment Considerations">
 <t> numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-deployment-considerations">Deployment Considerations</name>
      <t pn="section-9-1">
 As long as LSR node dataplane data-plane capabilities are limited (number of labels that can be pushed, pushed or number of labels that can be inspected), hop-by-hop load-balancing of SPRING encapsulated SPRING-encapsulated flows will require trade-offs.
      </t>
 <t>
      <t pn="section-9-2">
 The entropy label is still a good and usable solution as it allows load-balancing without having to perform deep packet inspection on each LSR: it It does not seem reasonable to have an LSR inspecting UDP ports within a GRE tunnel carried over a 15 label 15-label SPRING tunnel.
      </t>
 <t>
      <t pn="section-9-3">
 Due to the limited capacity of reading a deep stack of MPLS labels, multiple ELI/ELs may be required within the stack stack, which directly impacts the capacity of the head-end to push a deep stack: each ELI/EL inserted requires two additional labels to be pushed.
      </t>
 <t>
      <t pn="section-9-4">
 Placement strategies of ELI/ELs are required to find the best trade-off. Multiple criteria could be taken into account account, and some level of customization (by the user) is required to accommodate different deployments.
 Since analyzing the path of each destination to determine the best ELI/EL placement may be time consuming for the control plane, we encourage implementations to find the best trade-off between simplicity, resource consumption, and load-balancing efficiency.
      </t>
 <t>
      <t pn="section-9-5">
 In the future, hardware and software capacity may increase dataplane data-plane capabilities and may remove some of these limitations, increasing load-balancing capability using entropy labels.
      </t>
    </section>
    <section anchor="other-options" title="Options considered">
 <t>Different numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-options-considered">Options Considered</name>
      <t pn="section-10-1">Different options that were considered to arrive at the recommended
   solution are documented in this section.
</t>
<t>
      <t pn="section-10-2">
These options are detailed here only for historical purposes.
</t>
      <section title="Single numbered="true" toc="include" removeInRFC="false" pn="section-10.1">
        <name slugifiedName="name-single-el-at-the-bottom-of-">Single EL at the bottom Bottom of the stack">
	<t> Stack</name>
        <t pn="section-10.1-1">
	In this option, a single EL is used for the entire label stack.  The
   source LSR S encodes the entropy label at the bottom of the
   label stack.  In the example described in <xref target="usecase"/>, target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>, it will result
   in the label stack at LSR S to look like &lt;L_N-P3, L_A-L1, L_N-D, ELI,
   EL&gt; &lt;remaining packet header&gt;.  Note that the notation in <xref target="RFC6790"/> target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>
   is used to describe the label stack.  An issue with this approach is
   that as the label stack grows due an increase in the number of SIDs,
   the EL goes correspondingly deeper in the label stack.  Hence, transit
   LSRs have to access a larger number of bytes in the packet header
   when making forwarding decisions.  In the example described in
   <xref target="usecase"/>, target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>, if we consider that the LSR P1 has an ERLD of 3, P1 would
   load-balance traffic poorly on the
   parallel links L3 and L4 since the EL is below the ERLD of P1.
   A load-balanced network design using this approach
   must ensure that all intermediate LSRs have the capability to
   read the maximum label stack depth as required for the
   application that uses source routed source-routed stacking.
        </t>
	<t>
        <t pn="section-10.1-2">
	   This option was rejected since there exist a number of hardware
   implementations which that have a low maximum readable label depth.
   Choosing this option can lead to a loss of load-balancing using EL in
   a significant part of the network when that is a critical requirement
   in a service-provider network.
        </t>
      </section>
      <section title="An numbered="true" toc="include" removeInRFC="false" pn="section-10.2">
        <name slugifiedName="name-an-el-per-segment-in-the-st">An EL per segment Segment in the stack">
	<t> Stack</name>
        <t pn="section-10.2-1">
	In this option, each segment/label in the stack can be given its own
	EL. When load-balancing is required to direct traffic on a segment,
	the source LSR pushes an &lt;ELI, EL&gt; before pushing the label
	associated to this segment . segment.  In the example described in <xref target="usecase"/>, target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>, the source label stack that is LSR S encoded label stack would
	be &lt;L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL&gt; EL&gt;, where all the ELs
	can be the same.  Accessing the EL at an intermediate LSR is
	independent of the depth of the label stack and hence hence, independent of
	the specific application that uses source routed source-routed tunnels with label
	stacking.  A drawback is that the depth of the label stack grows
	significantly, almost 3 times as the number of labels in the label
	stack.  The network design should ensure that source LSRs have the
	capability to push such a deep label stack.  Also, the bandwidth
	overhead and potential MTU issues of deep label stacks should be
	considered in the network design.
        </t>
	<t>
        <t pn="section-10.2-2">
	This option was rejected due to the existence of hardware
   implementations that can push a limited number of labels on the label
   stack.  Choosing this option would result in a hardware requirement
   to push two additional labels per tunnel label.  Hence  Hence, it would
   restrict the number of tunnels that can be stacked in a an LSP and hence hence,
   constrain the types of LSPs that can be created.  This was considered
   unacceptable.
        </t>
      </section>
      <section title="A re-usable numbered="true" toc="include" removeInRFC="false" pn="section-10.3">
        <name slugifiedName="name-a-reusable-el-for-a-stack-o">A Reusable EL for a stack Stack of tunnels">
	<t> Tunnels</name>
        <t pn="section-10.3-1">
	In this option option, an LSR that terminates a tunnel re-uses reuses the EL of the
	terminated tunnel for the next inner tunnel.  It does this by storing
	the EL from the outer tunnel when that tunnel is terminated and re-
   inserting
	reinserting it below the next inner tunnel label during the label swap label-swap
	operation.  The LSR that stacks tunnels should insert an EL below the
	outermost tunnel.  It should not insert ELs for any inner tunnels.
	Also, the penultimate hop LSR of a segment must not pop the ELI and EL
	even though they are exposed as the top labels since the terminating
	LSR of that segment would re-use reuse the EL for the next segment.
        </t>
	<t>
        <t pn="section-10.3-2">
	In <xref target="usecase"/> above, target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>, the source label stack that is LSR S
 encoded label stack would be &lt;L_N-P3, ELI, EL, L_A-L1, L_N-D&gt;. L_N-⁠D&gt;.  At P1, the
 outgoing label stack would be &lt;L_N-P3, ELI, EL, L_A-L1, L_N-D&gt;
 after it has load-balanced to one of the links L3 or L4.  At P3 P3, the
 outgoing label stack would be &lt;L_N-D, ELI, EL&gt;.  At P2, the
 outgoing label stack would be &lt;L_N-D, ELI, EL&gt; and it would
 load-balance to one of the nexthop next-hop LSRs P4 or P5.  Accessing the EL at
 an intermediate LSR (e.g., P1) is independent of the depth of the
 label stack and hence hence, independent of the specific use-case use case to which
 the label stack is applied.
        </t>
	<t>
        <t pn="section-10.3-3">
	This option was rejected due to the significant change in label swap label-swap
   operations that would be required for existing hardware.
        </t>
      </section>
      <section title="EL numbered="true" toc="include" removeInRFC="false" pn="section-10.4">
        <name slugifiedName="name-el-at-top-of-stack">EL at top Top of stack">
	<t> Stack</name>
        <t pn="section-10.4-1">
	A slight variant of the re-usable reusable EL option is to keep the EL at the
   top of the stack rather than below the tunnel label.  In this case,
   each LSR that is not terminating a segment should continue to keep
   the received EL at the top of the stack when forwarding the packet
   along the segment.  An LSR that terminates a segment should use the
   EL from the terminated segment at the top of the stack when
   forwarding onto the next segment.
        </t>
	<t>
        <t pn="section-10.4-2">
	This option was rejected due to the significant change in label swap
   operations that would be required for existing hardware.
        </t>
      </section>
      <section title="ELs numbered="true" toc="include" removeInRFC="false" pn="section-10.5">
        <name slugifiedName="name-els-at-readable-label-stack">ELs at readable label stack depths">
	<t> Readable Label Stack Depths</name>
        <t pn="section-10.5-1">
	In this option option, the source LSR inserts ELs for tunnels in the label
	stack at depths such that each LSR along the path that must load
   balance load-balance is able to access at least one EL.  Note that the source LSR
	may have to insert multiple ELs in the label stack at different depths
	for this to work since intermediate LSRs may have differing
	capabilities in accessing the depth of a label stack.  The label stack
	depth access value of intermediate LSRs must be known to create such a
	label stack.  How this value is determined is outside the scope of
	this document.  This value can be advertised using a protocol such as
	an IGP.
        </t>
	<t>
        <t pn="section-10.5-2">
	   Applying this method to the example in <xref target="usecase"/> above, target="usecase" format="default" sectionFormat="of" derivedContent="Section 3"/>, if LSR P1
   needs to have the EL within a depth of 4, then the source label stack that
   is LSR S encoded label stack would be &lt;L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI,
   EL&gt;
   EL&gt;, where all the ELs would typically have the same value.
        </t>
	<t>
        <t pn="section-10.5-3">
	In the case where the ERLD has different values along the path and the
   LSR that is inserting &lt;ELI, EL&gt; pairs has no limit on how many pairs
   it can insert, and it knows the appropriate positions in the stack
   where they should be inserted, this option is the same as the
	recommended solution in <xref target="solution"/>. target="solution" format="default" sectionFormat="of" derivedContent="Section 7"/>.
        </t>
	<t>
        <t pn="section-10.5-4">
	Note that a refinement of this solution solution, which balances the number of
   pushed labels against the desired entropy entropy, is the solution described
   in <xref target="solution"/>. target="solution" format="default" sectionFormat="of" derivedContent="Section 7"/>.
        </t>
      </section>
    </section>
    <section title="Acknowledgements">
 <t>The authors would like to thank John Drake, Loa Andersson, Curtis
   Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro, Bruno Decraene, Chris Bowers, Nobo Akiya, Daniele Ceccarelli and Joe Clarke for
   their review comments and suggestions. toc="include" numbered="true" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-11-1"> This document has no IANA actions.
</t>
    </section>
    <section title="Contributors">
 <figure>
 <artwork>
   Xiaohu Xu
   Huawei

   Email: xuxiaohu@huawei.com

   Wim Hendrickx
   Nokia

   Email: wim.henderickx@nokia.com

   Gunter Van De Velde
   Nokia

   Email: gunter.van_de_velde@nokia.com

   Acee Lindem
   Cisco

   Email: acee@cisco.com

 </artwork>
 </figure>
 </section>

    <section title="IANA Considerations" toc="default">
<t>     This memo includes no request to IANA.  Note to RFC Editor: Remove
   this section before publication.
</t>

    </section>
	 <section title="Security Considerations" toc="default">
<t>Compared toc="include" numbered="true" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-12-1">Compared to <xref target="RFC6790"/>, target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>, this document introduces the notion
of ERLD, MSD ERLD and MSD, and may require an ingress node to push multiple ELI/EL. ELIs/ELs.
These changes does do not introduce any new security considerations beyond those
already listed in <xref target="RFC6790"/>. target="RFC6790" format="default" sectionFormat="of" derivedContent="RFC6790"/>.
</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-idr-bgp-ls-segment-routing-msd" to="MSD-BGP"/>
    <displayreference target="I-D.ietf-isis-mpls-elc" to="ISIS-ELC"/>
    <displayreference target="I-D.ietf-ospf-mpls-elc" to="OSPF-ELC"/>
    <references title="Normative References">
	&RFC2119;
	&RFC6790;
	&RFC8174;
	&SR;
	&SR-MPLS;
    </references> pn="section-13">
      <name slugifiedName="name-references">References</name>
      <references title="Informative References">
	&ISIS-ELC;
	&OSPF-ELC;
	&SR-L2-BUNDLES;
	&RFC7855;
	&ISIS-MSD;
	&OSPF-MSD;
	&BGP-MSD;
    </references> pn="section-13.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC6790" target="https://www.rfc-editor.org/info/rfc6790" quoteTitle="true" derivedAnchor="RFC6790">
          <front>
            <title>The Use of Entropy Labels in MPLS Forwarding</title>
            <author initials="K." surname="Kompella" fullname="K. Kompella">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Drake" fullname="J. Drake">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Amante" fullname="S. Amante">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="W." surname="Henderickx" fullname="W. Henderickx">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Yong" fullname="L. Yong">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="November"/>
            <abstract>
              <t>Load balancing is a powerful tool for engineering traffic across a network.  This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels".  It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications.  This document updates RFCs 3031, 3107, 3209, and 5036.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6790"/>
          <seriesInfo name="DOI" value="10.17487/RFC6790"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" quoteTitle="true" derivedAnchor="RFC8402">
          <front>
            <title>Segment Routing Architecture</title>
            <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Decraene" fullname="B. Decraene">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Litkowski" fullname="S. Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Shakir" fullname="R. Shakir">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="July"/>
            <abstract>
              <t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called "segments".  A segment can represent any instruction, topological or service based.  A segment can have a semantic local to an SR node or global within an SR domain.  SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
              <t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane.  A segment is encoded as an MPLS label.  An ordered list of segments is encoded as a stack of labels.  The segment to process is on the top of the stack.  Upon completion of a segment, the related label is popped from the stack.</t>
              <t>SR can be applied to the IPv6 architecture, with a new type of routing header.  A segment is encoded as an IPv6 address.  An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header.  The active segment is indicated by the Destination Address (DA) of the packet.  The next active segment is indicated by a pointer in the new routing header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8402"/>
          <seriesInfo name="DOI" value="10.17487/RFC8402"/>
        </reference>
        <reference anchor="RFC8660" target="https://www.rfc-editor.org/info/rfc8660" quoteTitle="true" derivedAnchor="RFC8660">
          <front>
            <title>Segment Routing with the MPLS Data Plane</title>
            <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Previdi" fullname="Stefano Previdi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R" surname="Shakir" fullname="Rob Shakir">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="2019"/>
          </front>
          <seriesInfo name="RFC" value="8660"/>
          <seriesInfo name="DOI" value="10.17487/RFC8660"/>
        </reference>
      </references>
      <references pn="section-13.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-isis-mpls-elc" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-10" derivedAnchor="ISIS-ELC">
          <front>
            <title>Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS</title>
            <author initials="X" surname="Xu" fullname="Xiaohu Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Kini" fullname="Sriganesh Kini">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P" surname="Psenak" fullname="Peter Psenak">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Bocci" fullname="Matthew Bocci">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" day="21" year="2019"/>
            <abstract>
              <t>Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL).  An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given Label Switched Path (LSP) unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as Entropy Label Capability (ELC), on that tunnel.  In addition, it would be useful for ingress LSRs to know each LSR's capability for reading the maximum label stack depth and performing EL-based load- balancing, referred to as Entropy Readable Label Depth (ERLD).  This document defines a mechanism to signal these two capabilities using IS-IS.  These mechanisms are particularly useful, where label advertisements are done via protocols like IS-IS.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-isis-mpls-elc-10"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-isis-mpls-elc-10.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-ospf-mpls-elc" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-ospf-mpls-elc-12" derivedAnchor="OSPF-ELC">
          <front>
            <title>Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF</title>
            <author initials="X" surname="Xu" fullname="Xiaohu Xu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Kini" fullname="Sriganesh Kini">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P" surname="Psenak" fullname="Peter Psenak">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Bocci" fullname="Matthew Bocci">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" day="25" year="2019"/>
            <abstract>
              <t>Multiprotocol Label Switching (MPLS) has defined a mechanism to load- balance traffic flows using Entropy Labels (EL).  An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it has the capability to process ELs, referred to as Entropy Label Capability (ELC), on that tunnel.  In addition, it would be useful for ingress LSRs to know each LSR's capability of reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD).  This document defines a mechanism to signal these two capabilities using OSPF and OSPFv3. These mechanism is particularly useful in the environment where Segment Routing (SR) is used, where label advertisements are done via protocols like OSPF and OSPFv3.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-ospf-mpls-elc-12"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ospf-mpls-elc-12.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC8668" target="https://www.rfc-editor.org/info/rfc8668" quoteTitle="true" derivedAnchor="RFC8668">
          <front>
            <title>Advertising Layer 2 Bundle Member Link Attributes in IS-IS</title>
            <author initials="L" surname="Ginsberg" fullname="Les Ginsberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Nanduri" fullname="Mohan Nanduri">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E" surname="Aries" fullname="Ebben Aries">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="December" year="2019"/>
          </front>
          <seriesInfo name="RFC" value="8668"/>
          <seriesInfo name="DOI" value="10.17487/RFC8668"/>
        </reference>
        <reference anchor="RFC7855" target="https://www.rfc-editor.org/info/rfc7855" quoteTitle="true" derivedAnchor="RFC7855">
          <front>
            <title>Source Packet Routing in Networking (SPRING) Problem Statement and Requirements</title>
            <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Decraene" fullname="B. Decraene">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Litkowski" fullname="S. Litkowski">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Horneffer" fullname="M. Horneffer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Shakir" fullname="R. Shakir">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="May"/>
            <abstract>
              <t>The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions.  Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption.  In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network).</t>
              <t>This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic.  Multicast use cases and requirements are out of scope for this document.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7855"/>
          <seriesInfo name="DOI" value="10.17487/RFC7855"/>
        </reference>
        <reference anchor="RFC8476" target="https://www.rfc-editor.org/info/rfc8476" quoteTitle="true" derivedAnchor="RFC8476">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using OSPF</title>
            <author initials="J." surname="Tantsura" fullname="J. Tantsura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="U." surname="Chunduri" fullname="U. Chunduri">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Aldrin" fullname="S. Aldrin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Psenak" fullname="P. Psenak">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="December"/>
            <abstract>
              <t>This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.  Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.  This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types.  Here, the term "OSPF" means both OSPFv2 and OSPFv3.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8476"/>
          <seriesInfo name="DOI" value="10.17487/RFC8476"/>
        </reference>
        <reference anchor="RFC8491" target="https://www.rfc-editor.org/info/rfc8491" quoteTitle="true" derivedAnchor="RFC8491">
          <front>
            <title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
            <author initials="J." surname="Tantsura" fullname="J. Tantsura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="U." surname="Chunduri" fullname="U. Chunduri">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Aldrin" fullname="S. Aldrin">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="November"/>
            <abstract>
              <t>This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network.  This document only defines one type of MSD: Base MPLS Imposition.  However, it defines an encoding that can support other MSD types.  This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8491"/>
          <seriesInfo name="DOI" value="10.17487/RFC8491"/>
        </reference>
        <reference anchor="I-D.ietf-idr-bgp-ls-segment-routing-msd" quoteTitle="true" target="https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-09" derivedAnchor="MSD-BGP">
          <front>
            <title>Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State</title>
            <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="U" surname="Chunduri" fullname="Uma Chunduri">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K" surname="Talaulikar" fullname="Ketan Talaulikar">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G" surname="Mirsky" fullname="Gregory Mirsky">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N" surname="Triantafillis" fullname="Nikos Triantafillis">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="October" day="15" year="2019"/>
            <abstract>
              <t>This document defines a way for a Border Gateway Protocol Link-State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.  Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-bgp-ls-segment-routing-msd-09"/>
          <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ls-segment-routing-msd-09.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-appendix.a-1">The authors would like to thank John Drake, Loa Andersson, Curtis
   Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro, Bruno Decraene, Chris Bowers, Nobo Akiya, Daniele Ceccarelli, and Joe Clarke for
   their review, comments, and suggestions.
</t>
    </section>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.b-1">
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.b-2">
Wim Hendrickx
Nokia
Email: wim.henderickx@nokia.com
</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.b-3">
Gunter Van de Velde
Nokia
Email: gunter.van_de_velde@nokia.com
</artwork>
      <artwork name="" type="" align="left" alt="" pn="section-appendix.b-4">
Acee Lindem
Cisco
Email: acee@cisco.com
</artwork>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="S" surname="Kini" fullname="Sriganesh Kini">
        <organization showOnFrontPage="true"/>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>sriganeshkini@gmail.com</email>
        </address>
      </author>
      <author initials="K" surname="Kompella" fullname="Kireeti Kompella">
        <organization showOnFrontPage="true">Juniper</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>kireeti@juniper.net</email>
        </address>
      </author>
      <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan">
        <organization showOnFrontPage="true">Cisco</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>msiva@cisco.com</email>
        </address>
      </author>
      <author initials="S" surname="Litkowski" fullname="Stephane Litkowski">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>slitkows.ietf@gmail.com</email>
        </address>
      </author>
      <author initials="R" surname="Shakir" fullname="Rob Shakir">
        <organization showOnFrontPage="true">Google</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>robjs@google.com</email>
        </address>
      </author>
      <author initials="J" surname="Tantsura" fullname="Jeff Tantsura">
        <organization showOnFrontPage="true">Apstra, Inc.</organization>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country/>
          </postal>
          <email>jefftant.ietf@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>