<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-ospf-mpls-elc-15" ipr="trust200902"> number="9089" ipr="trust200902"
     obsoletes="" updates="" submissionType="IETF" category="std"
     consensus="true" xml:lang="en" tocInclude="true" tocDepth="3"
     symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="Signaling ELC and ERLD using Using OSPF">Signaling Entropy Label
    Capability and Entropy Readable Label Depth Using OSPF</title>
    <seriesInfo name="RFC" value="9089"/>
    <author fullname="Xiaohu Xu" initials="X.X." initials="X." surname="Xu">
      <organization>Alibaba Inc</organization>
      <organization>Capitalonline</organization>
      <address>
        <!--
       <postal>
         <street></street>
-->

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

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

         <region></region>

         <code></code>

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

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

        <email>xiaohu.xxh@alibaba-inc.com</email>

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

        <email>xiaohu.xu@capitalonline.net</email>

      </address>
    </author>
    <author fullname="Sriganesh Kini" initials="S.K" initials="S." surname="Kini">
      <organization/>
      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <code/>

          <country/>
        </postal>

        <phone/>

        <facsimile/>
        <email>sriganeshkini@gmail.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>Eurovea
          <extaddr>Eurovea Centre, Central 3</street> 3</extaddr>
          <street>Pribinova Street 10</street>
          <city>Bratislava</city>
          <code>81109</code>
          <country>Slovakia</country>
        </postal>
        <email>ppsenak@cisco.com</email>
      </address>
    </author>
    <author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street/>
          <city>Brussels</city>
          <region/>
          <code/>
          <country>Belgium</country>
        </postal>
        <email>cfilsfil@cisco.com</email>
      </address>
    </author>
    <author fullname="Stephane Litkowski" initials="S.L." initials="S." surname="Litkowski">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>La Rigourdiere</street>
          <city>Cesson Sevigne</city>
          <code/>
          <country>France</country>
        </postal>
        <email>slitkows@cisco.com</email>
        <uri/>
      </address>
    </author>

 <author fullname="Matthew Bocci" initials="M.B." initials="M." surname="Bocci">
      <organization>Nokia</organization>
      <address>
        <postal>
          <street>Shoppenhangers Road</street>

          <city>Maidenhead, Berks</city>

          <code/>

          <country>UK</country>
          <street>Aztec West Business Park</street>
          <city>Bristol</city>
          <extaddr>740 Waterside Drive</extaddr>
          <code>BS32 4UF</code>
          <country>United Kingdom</country>
        </postal>
        <email>matthew.bocci@nokia.com</email>
        <uri/>
      </address>
 </author>
    <date/>

    <area>Routing Area</area>

    <workgroup>LSR Working Group</workgroup>

    <keyword>Sample</keyword>

    <keyword>Draft</keyword>

    <date year="2021" month="August"/>
    <area>RTG</area>
    <workgroup>LSR</workgroup>

    <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 the Entropy Label Capability
      (ELC), on that LSP. 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 OSPFv2 and OSPFv3 OSPFv3, and BGP-LS.</t> Border Gateway Protocol - Link
      State (BGP-LS).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC6790"/> target="RFC6790" format="default"/> describes a method to load-balance
      Multiprotocol Label Switching (MPLS) traffic flows using Entropy Labels
      (EL). It also introduces the concept of Entropy Label
      Capability (ELC) and defines the signaling of this capability via MPLS
      signaling protocols. Recently, mechanisms have been defined to signal
      labels via link-state Interior Gateway Protocols (IGP) such as OSPFv2
      <xref target="RFC8665"/> target="RFC8665" format="default"/> and OSPFv3 <xref target="RFC8666"/>. target="RFC8666" format="default"/>.
      This draft document defines a mechanism to signal the ELC using OSPFv2 and OSPFv3.</t>
      <t>In cases where Segment Routing (SR) is used with the MPLS Data Plane data plane
      (e.g., SR-MPLS <xref target="RFC8660"/>), target="RFC8660" format="default"/>), it would be
      useful for ingress LSRs to know each intermediate LSR's capability of
      reading the maximum label stack depth and performing EL-based
      load-balancing.  This capability, referred to as Entropy Readable Label
      Depth (ERLD) as defined in <xref target="RFC8662"/>, target="RFC8662" format="default"/>,
      may be used by ingress LSRs to determine the position of the EL label in
      the stack, and whether it is necessary to insert multiple ELs at
      different positions in the label stack. This document defines a
      mechanism to signal the ERLD using OSPFv2 and OSPFv3.</t>
    </section>
    <section anchor="Teminology" title="Terminology"> numbered="true" toc="default">
      <name>Terminology</name>

      <t>This memo makes use of the terms defined in <xref target="RFC6790"/>, target="RFC6790"
      format="default"/> and <xref target="RFC8662"/>.</t> target="RFC8662" format="default"/>.</t>
      <t>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&nbsp;14 <xref target="RFC2119"/> target="RFC2119"
      format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when, and
      only when, they appear in all capitals, as shown here.</t>

      <t>The key word OSPF is used throughout the document to refer to both OSPFv2 and
       OSPFv3.</t>
    </section>
    <section anchor="ELC_ADV" title="Advertising numbered="true" toc="default">
      <name>Advertising ELC Using OSPF"> OSPF</name>
      <t>Even though ELC is a property of the node, in some cases it is advantageous
      to associate and advertise the ELC with a prefix. In multi-area networks,
      routers may not know the identity of the prefix originator in a remote area, area
      or may not know the capabilities of such an originator. Similarly, in a multi domain multi-domain
      network, the identity of the prefix originator and its capabilities may not be
      known to the ingress LSR.</t>
      <t>If a router has multiple interfaces, the router MUST NOT <bcp14>MUST NOT</bcp14> announce ELC
      unless all of its interfaces are capable of processing ELs.</t>
      <t>If the router supports ELs on all of its interfaces, it SHOULD
      <bcp14>SHOULD</bcp14> advertise the ELC with every local host prefix it
      advertises in OSPF.</t>
      <section anchor="Advertising_OSPFv2" title="Advertising numbered="true" toc="default">
        <name>Advertising ELC Using OSPFv2"> OSPFv2</name>
        <t><xref target="RFC7684"/> target="RFC7684" format="default"/> defines the OSPFv2
        Extended Prefix TLV to advertise additional attributes associated with
        a prefix. The OSPFv2 Extended Prefix TLV includes a one-octet Flags
        field. A new flag in the Flags field is used to signal the ELC for the
        prefix:

      <list style="hanging">

      <t>0x20

        </t>
        <dl newline="true" spacing="normal">

          <dt>0x20 - E-Flag (ELC Flag): Flag):</dt><dd> Set by the advertising router
          to indicate that the prefix originator is capable of processing ELs.</t>

      </list></t>
          ELs.</dd>
        </dl>

        <t>The ELC signaling MUST <bcp14>MUST</bcp14> be preserved when an OSPF
        Area Border Router (ABR) distributes information between areas. To do
        so, an ABR MUST <bcp14>MUST</bcp14> originate an OSPFv2 Extended Prefix
        Opaque LSA Link State Advertisement (LSA) <xref target="RFC7684"/> target="RFC7684" format="default"/> including the
        received ELC setting.</t>
        <t>When an OSPF Autonomous System Boundary Border Router (ASBR) redistributes
        a prefix from another instance of OSPF or from some other protocol, it SHOULD
        <bcp14>SHOULD</bcp14> preserve the ELC signaling for the prefix if it
        exists. To do so, an ASBR SHOULD <bcp14>SHOULD</bcp14> originate an Extended
        Prefix Opaque LSA <xref target="RFC7684"/> target="RFC7684" format="default"/> including
        the ELC setting of the redistributed prefix. The flooding scope of the
        Extended Prefix Opaque LSA MUST <bcp14>MUST</bcp14> match the flooding
        scope of the LSA that an ASBR originates as a result of the
        redistribution. The exact mechanism used to exchange ELC between
        protocol instances on an ASBR is outside of the scope of this
        document.</t>
      </section>
      <section anchor="Advertising_OSPFv3" title="Advertising numbered="true" toc="default">
        <name>Advertising ELC Using OSPFv3"> OSPFv3</name>
        <t><xref target="RFC5340"/> target="RFC5340" format="default"/> defines the OSPFv3
        PrefixOptions field to indicate capabilities associated with a
        prefix. A new bit in the OSPFv3 PrefixOptions field is used to signal the
        ELC for the prefix:

      <list style="hanging">

      <t>0x40
        </t>

    <dl newline="true" spacing="normal">

         <dt> 0x40 - E-Flag (ELC Flag): Flag):</dt><dd> Set by the advertising router to
      indicate that the prefix originator is capable of processing ELs.</t> ELs.</dd>
	</dl>

          <t>The ELC signaling MUST <bcp14>MUST</bcp14> be preserved when an OSPFv3
          Area Border Router (ABR) distributes information between areas. The
          setting of the ELC Flag in the Inter-Area-Prefix-LSA <xref target="RFC5340"/>
          target="RFC5340" format="default"/> or in the Inter-Area-Prefix TLV
          <xref target="RFC8362"/>, target="RFC8362" format="default"/>, generated by an ABR, MUST
          <bcp14>MUST</bcp14> be the same as the value the ELC Flag associated
          with the prefix in the source area.</t>

          <t>When an OSPFv3 Autonomous System Boundary Border Router (ASBR)
          redistributes a prefix from another instance of OSPFv3 or from some
          other protocol, it SHOULD <bcp14>SHOULD</bcp14> preserve the ELC signaling
          for the prefix if it exists. The setting of the ELC Flag in the
          AS-External-LSA, NSSA-LSA Not-So-Stubby Area LSA (NSSA-LSA) <xref target="RFC5340"/> target="RFC5340" format="default"/>,
          or in the External-Prefix TLV <xref target="RFC8362"/>, target="RFC8362"
          format="default"/>, generated by an ASBR, MUST <bcp14>MUST</bcp14> be the
          same as the value of the ELC Flag associated with the prefix in the
          source domain.  The exact mechanism used to exchange ELC between
          protocol instances on the ASBR is outside of the scope of this
          document.</t>

      </list></t>

      </section>
    </section>
    <section anchor="ERLD_ADV" title="Advertising numbered="true" toc="default">
      <name>Advertising ERLD Using OSPF"> OSPF</name>
      <t>The ERLD is advertised in a Node MSD Maximum SID Depth (MSD) TLV [RFC8476] <xref
      target="RFC8476"/> using the ERLD-MSD type defined in <xref target="I-D.ietf-isis-mpls-elc"/>.</t>
      target="RFC9088" format="default"/>.</t>
      <t>If a router has multiple interfaces with different capabilities of
      reading the maximum label stack depth, the router MUST <bcp14>MUST</bcp14>
      advertise the smallest value found across all of its interfaces.</t>
      <t>The absence of ERLD-MSD advertisements indicates only that the advertising
      node does not support advertisement of this capability.</t>
      <t>When the ERLD-MSD type is received in the OSPFv2 or OSPFv3 Link MSD Sub-TLV sub-TLV
      <xref target="RFC8476"/>, target="RFC8476" format="default"/>, it MUST <bcp14>MUST</bcp14> be ignored.</t>
      <t>The considerations for advertising the ERLD are specified in
      <xref target="RFC8662"/>.</t> target="RFC8662" format="default"/>.</t>
    </section>
    <section anchor="BGPLS" title="Signaling numbered="true" toc="default">
      <name>Signaling ELC and ERLD in BGP-LS"> BGP-LS</name>
      <t>The OSPF extensions defined in this document can be advertised via
   BGP-LS (Distribution (distribution of Link-State and TE Information Using information using BGP) <xref target="RFC7752"/> target="RFC7752" format="default"/>
   using existing BGP-LS TLVs.</t>
      <t>The ELC is advertised using the Prefix Attribute Flags TLV as defined in
   <xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t> target="RFC9085" format="default"/>.</t>
      <t>The ERLD-MSD is advertised using the Node MSD TLV as defined in
   <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/>.</t> target="RFC8814" format="default"/>.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations">

   <t>Early allocation numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has been done by IANA completed the following actions for this document as follows:

      <list style="hanging">

      <t>- document:
      </t>
      <ul>

        <li> Flag 0x20 in the OSPFv2 "OSPFv2 Extended Prefix TLV Flags Flags" registry has been
      allocated by IANA to the E-Flag (ELC Flag).</t>

      <t>- Flag).</li>

        <li> Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
      allocated by IANA to the E-Flag (ELC Flag).</t>

      </list></t> Flag).</li>
      </ul>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document specifies the ability to advertise additional node
      capabilities using OSPF and BGP-LS.  As such, the security
      considerations as described in <xref target="RFC5340"/>, target="RFC5340"
      format="default"/>, <xref target="RFC7770"/>, target="RFC7684" format="default"/>, <xref target="RFC7752"/>,
      target="RFC7752" format="default"/>, <xref target="RFC7684"/>, target="RFC7770"
      format="default"/>, <xref target="RFC8476"/>, target="RFC8476" format="default"/>, <xref target="RFC8662"/>,
      target="RFC8662" format="default"/>, <xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/> target="RFC8814"
      format="default"/>, and <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/> target="RFC9085" format="default"/> are
      applicable to this document.</t>
      <t>Incorrectly setting the E flag E-Flag during origination, propagation propagation, or
      redistribution may lead to poor or no load-balancing of the MPLS traffic
      or black-holing of to the MPLS traffic being discarded on the egress node.</t> node.
      </t>
      <t>Incorrectly setting of the ERLD value may lead to poor or no load-balancing of the
      MPLS traffic.</t>
    </section>

  </middle>
  <back>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7684.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8476.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8662.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8362.xml"/>

        <xi:include  href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8814.xml"/>

<reference anchor='RFC9088' target='https://www.rfc-editor.org/info/rfc9088'>
  <front>
    <title>Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS</title>

    <author initials='X' surname='Xu' fullname='Xiaohu Xu'>
      <organization />
    </author>

    <author initials='S' surname='Kini' fullname='Sriganesh Kini'>
      <organization />
    </author>

    <author initials='P' surname='Psenak' fullname='Peter Psenak'>
      <organization />
    </author>

    <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
      <organization />
    </author>

    <author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
      <organization />
    </author>

    <author initials='M' surname='Bocci' fullname='Matthew Bocci'>
      <organization />
    </author>

    <date month='August' year='2021' />

  </front>
  <seriesInfo name="RFC" value="9088"/>
  <seriesInfo name="DOI" value="10.17487/RFC9088"/>
</reference>

<reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
<front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing</title>

<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
    <organization />
</author>

<author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='editor'>
    <organization />
</author>

<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
    <organization />
</author>

<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
    <organization />
</author>

<author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
    <organization />
</author>

<date month='August' year='2021' />

</front>
<seriesInfo name="RFC" value="9085"/>
<seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>

      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8660.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8665.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8666.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Yimin Shen"/>,
      <contact fullname="George Swallow"/>, <contact fullname="Acee Lindem"/>,
      <contact fullname="Les Ginsberg"/>, <contact fullname="Ketan
      Talaulikar"/>, <contact fullname="Jeff Tantsura"/> , <contact
      fullname="Bruno Decraene"/>, and <contact fullname="Carlos Pignataro"/>
      for their valuable comments.</t>

    </section>

    <section anchor="CONTR" title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people contributed to the content
      of this document and should be considered as co-authors:</t>

      <t><figure>
          <artwork><![CDATA[

   Gunter coauthors:</t>

       <contact fullname="Gunter Van de Velde (editor)
   Nokia
   Antwerp
   BE

   Email: gunter.van_de_velde@nokia.com

   Wim Henderickx
   Nokia
   Belgium

   Email: wim.henderickx@nokia.com

   Keyur Patel
   Arrcus
   USA

   Email: keyur@arrcus.com

]]></artwork>
        </figure></t>

   </section>

   <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Yimin Shen, George Swallow, Acee
      Lindem, Les Ginsberg, Ketan Talaulikar, Jeff Tantsura , Bruno Decraene
      and Carlos Pignataro for their valuable comments.</t>

      <!----> (editor)">

	 <organization>Nokia</organization>
	 <address>
	   <postal>
	     <city>Antwerp</city>
	     <country>Belgium</country>
	   </postal>

	   <email>gunter.van_de_velde@nokia.com</email>
	 </address>
       </contact>

   <contact fullname="Wim Henderickx">
     <organization>Nokia</organization>
     	 <address>
	   <postal>
	     <country>Belgium</country>
	   </postal>

	   <email>wim.henderickx@nokia.com</email>
	 </address>
   </contact>

   <contact fullname="Keyur Patel">
     <organization>Arrcus</organization>
     	 <address>
	   <postal>
	     <country>United States of America</country>
	       </postal>

	       <email>keyur@arrcus.com</email>
	       	 </address>
       </contact>

    </section>

  </middle>

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

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

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

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

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

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

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

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

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

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

      <?rfc include="reference.I-D.ietf-isis-mpls-elc"?>

      <?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext"?>

      <?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-msd"?>

    </references>

    <references title="Informative References">

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

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

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

 </back>
</rfc>