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

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-ospf-mpls-elc-15" 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 OSPF">Signaling Entropy Label
    Capability and Entropy Readable Label Depth Using OSPF</title>
    <seriesInfo name="RFC" value="9089"/>
    <author fullname="Xiaohu Xu" initials="X." surname="Xu">
      <organization>Capitalonline</organization>
      <address>
 
        <email>xiaohu.xu@capitalonline.net</email>
 
      </address>
    </author>
    <author fullname="Sriganesh Kini" initials="S." surname="Kini">
      <organization/>
      <address>
        <email>sriganeshkini@gmail.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Peter Psenak" initials="P." surname="Psenak">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <extaddr>Eurovea Centre, Central 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." 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." surname="Bocci">
      <organization>Nokia</organization>
      <address>
        <postal>
          <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 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, and Border Gateway Protocol - Link
      State (BGP-LS).</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref 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" format="default"/> and OSPFv3 <xref target="RFC8666" format="default"/>. 
      This 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
      (e.g., SR-MPLS <xref 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" 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" numbered="true" toc="default">
      <name>Terminology</name>

      <t>This memo makes use of the terms defined in <xref target="RFC6790"
      format="default"/> and <xref target="RFC8662" format="default"/>.</t>
      <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are
      to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
      format="default"/> <xref 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" numbered="true" toc="default">
      <name>Advertising ELC Using 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
      or may not know the capabilities of such an originator. Similarly, in a 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 <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
      <bcp14>SHOULD</bcp14> advertise the ELC with every local host prefix it
      advertises in OSPF.</t>
      <section anchor="Advertising_OSPFv2" numbered="true" toc="default">
        <name>Advertising ELC Using OSPFv2</name>
        <t><xref 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:
      
        </t>
        <dl newline="true" spacing="normal">
          
          <dt>0x20 - E-Flag (ELC Flag):</dt><dd> Set by the advertising router
          to indicate that the prefix originator is capable of processing
          ELs.</dd>
        </dl>
	
        <t>The ELC signaling <bcp14>MUST</bcp14> be preserved when an OSPF
        Area Border Router (ABR) distributes information between areas. To do
        so, an ABR <bcp14>MUST</bcp14> originate an OSPFv2 Extended Prefix
        Opaque Link State Advertisement (LSA) <xref target="RFC7684" format="default"/> including the
        received ELC setting.</t>
        <t>When an OSPF Autonomous System Border Router (ASBR) redistributes
        a prefix from another instance of OSPF or from some other protocol, it
        <bcp14>SHOULD</bcp14> preserve the ELC signaling for the prefix if it
        exists. To do so, an ASBR <bcp14>SHOULD</bcp14> originate an Extended
        Prefix Opaque LSA <xref target="RFC7684" format="default"/> including
        the ELC setting of the redistributed prefix. The flooding scope of the
        Extended Prefix Opaque LSA <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" numbered="true" toc="default">
        <name>Advertising ELC Using OSPFv3</name>
        <t><xref 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:    
        </t>

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

          <t>The ELC signaling <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" format="default"/> or in the Inter-Area-Prefix TLV
          <xref target="RFC8362" format="default"/>, generated by an ABR,
          <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 Border Router (ASBR)
          redistributes a prefix from another instance of OSPFv3 or from some
          other protocol, it <bcp14>SHOULD</bcp14> preserve the ELC signaling
          for the prefix if it exists. The setting of the ELC Flag in the
          AS-External-LSA, Not-So-Stubby Area LSA (NSSA-LSA) <xref target="RFC5340" format="default"/>,
          or in the External-Prefix TLV <xref target="RFC8362"
          format="default"/>, generated by an ASBR, <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>
      
      </section>
    </section>
    <section anchor="ERLD_ADV" numbered="true" toc="default">
      <name>Advertising ERLD Using OSPF</name>
      <t>The ERLD is advertised in a Node Maximum SID Depth (MSD) TLV <xref
      target="RFC8476"/> using the ERLD-MSD type defined in <xref
      target="RFC9088" format="default"/>.</t>
      <t>If a router has multiple interfaces with different capabilities of
      reading the maximum label stack depth, the router <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
      <xref target="RFC8476" format="default"/>, it <bcp14>MUST</bcp14> be ignored.</t>
      <t>The considerations for advertising the ERLD are specified in 
      <xref target="RFC8662" format="default"/>.</t>
    </section>
    <section anchor="BGPLS" numbered="true" toc="default">
      <name>Signaling ELC and ERLD in BGP-LS</name>
      <t>The OSPF extensions defined in this document can be advertised via
   BGP-LS (distribution of Link-State and TE information using BGP) <xref 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="RFC9085" format="default"/>.</t>
      <t>The ERLD-MSD is advertised using the Node MSD TLV as defined in
   <xref target="RFC8814" format="default"/>.</t>
    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA has completed the following actions for this document:
      </t>
      <ul>
      
        <li> Flag 0x20 in the "OSPFv2 Extended Prefix TLV Flags" registry has been
      allocated to the E-Flag (ELC Flag).</li>
    
        <li> Bit 0x40 in the "OSPFv3 Prefix Options (8 bits)" registry has been
      allocated to the E-Flag (ELC Flag).</li>
      </ul>
    </section>
    <section anchor="Security" 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"
      format="default"/>, <xref target="RFC7684" format="default"/>, <xref
      target="RFC7752" format="default"/>, <xref target="RFC7770"
      format="default"/>, <xref target="RFC8476" format="default"/>, <xref
      target="RFC8662" format="default"/>, <xref target="RFC8814"
      format="default"/>, and <xref target="RFC9085" format="default"/> are
      applicable to this document.</t>
      <t>Incorrectly setting the E-Flag during origination, propagation, or
      redistribution may lead to poor or no load-balancing of the MPLS traffic
      or to the MPLS traffic being discarded on the egress 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" numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people contributed to the content
      of this document and should be considered coauthors:</t>


       <contact fullname="Gunter Van de Velde (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>

 </back>
</rfc>
