<?xml version='1.0'?>   
    <!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [ 
    	<!ENTITY rfc2629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'> 
		]>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-peng-pce-entropy-label-position-07"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->
  <front>
    <title abbrev="PCEP Extension for SR-MPLS Entropy Label Position">PCEP Extension for SR-MPLS Entropy Label Position</title>
	
	
	 <author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>

      <address>
        <postal>
          <street>No.6 Huashi Park Rd</street>
          
          <city>Wuhan</city>
          
          <region>Hubei</region>
  
          <code>430223</code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>xiong.quan@zte.com.cn</email>
      </address>
    </author>
	
	<author fullname="Shaofu Peng" initials="S" surname="Peng">
      <organization>ZTE Corporation</organization>

      <address>
        <postal>
          <street>No.50 Software Avenue</street>
          
          <city>Nanjing</city>
          
          <region>Jiangsu</region>
  
          <code>210012</code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>peng.shaofu@zte.com.cn</email>
      </address>
    </author>
	
	
	<author fullname="Fengwei Qin" initials="F" surname="Qin">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street></street>
          
          <city>Beijing</city>
          
          <region></region>
  
          <code></code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>qinfengwei@chinamobile.com</email>
      </address>
    </author>
    
   <date month="March" year="2022"/>	
    <area>Routing</area>
    <workgroup>PCE</workgroup>
    <keyword></keyword>
    <abstract>
     <t>This document proposes a set of extensions for PCEP to configure 
	 the entropy label position for SR-MPLS networks.</t>
    </abstract>
  </front>

  <!-- ***** MIDDLE MATTER ***** -->

  <middle>
  
    <section title="Introduction">
	
	<t><xref target="RFC5440"></xref> describes the Path Computation Element 
    Protocol (PCEP) which is used between a Path Computation Element (PCE) 
    and a Path Computation Client (PCC) (or other PCE) to enable computation 
    of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 
    Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model <xref target="RFC8231"></xref> 
	describes a set of extensions to PCEP to enable active control of MPLS-TE and 
	Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281"></xref> describes the setup and teardown of 
    PCE-initiated LSPs under the active stateful PCE model, without the need 
    for local configuration on the PCC, thus allowing for dynamic centralized
    control of a network.</t>
	
	<t>Segment Routing (SR) leverages the source routing paradigm. Segment 
	Routing can be instantiated on MPLS data plane which is referred to as 
	SR-MPLS <xref target="RFC8660"></xref>. SR-MPLS leverages the 
	MPLS label stack to construct the SR path. PCEP Extensions for Segment 
	Routing <xref target="RFC8664"></xref> specifies extensions to the PCEP 
	that allow a stateful PCE to compute and initiate TE paths, as well as
	a PCC to request a path subject to certain constraint(s) and optimization
	criteria in SR networks.</t>
	
	<t>Entropy label (EL) <xref target="RFC6790"></xref> is a technique used in the MPLS data plane 
	to improve load-balancing. Entropy Label Indicator (ELI) can be
	immediately preceding an EL in the MPLS label stack. The idea behind the EL
	is that the ingress router computes a hash based on several fields from 
	a given packet and places the result in an additional 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 and an LSR may use solely the entropy label or a combination of 
	multiple fields from the incoming packet.</t>
	
	<t><xref target="RFC8662"></xref> proposes to use entropy labels for 
	SR-MPLS networks and mutiple &lt;ELI, EL&gt; pairs SHOULD be inserted 
	in the SR-MPLS label stack. The ingress node may decide the number and
    place of the ELI/ELs which need to be inserted into the label stack. 
	The extensions for Border Gateway Protocol (BGP) to indicate the entropy 
	label position in the SR-MPLS label stack has been proposed in 
	<xref target="I-D.zhou-idr-bgp-srmpls-elp"></xref>.</t>
	
	
	<t>In some cases, the the controller(e.g. PCE) could be used to perform 
	the TE path computation as well as the Entropy Label Position (ELP) 
	which is useful for inter-domain scenarios. This document proposes a 
	set of extensions for PCEP to configure the ELP information for SR-MPLS
	networks.</t>
  
   </section>

    <section title="Conventions used in this document">	 	
    <section title="Terminology">
	<t>The terminology is defined as <xref target="RFC5440"></xref>, <xref target="RFC6790"></xref>, <xref target="RFC8664"></xref>
	and <xref target="RFC8662"></xref>.</t>
   </section>
   
   <section title="Requirements Language">
    <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in BCP
    14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,
    and only when, they appear in all capitals, as shown here.</t>
    </section>
	
   </section>
   <section title="Entropy Labels in SR-MPLS Scenario with PCE ">
   
   <t><xref target="RFC8662"></xref> proposes to use entropy labels 
	for SR-MPLS networks. The Entropy Readable Label Depth (ERLD) is defined 
	as the number of labels which means that the router will perform 
	load-balancing using the ELI/EL. An appropriate algorithm should consider 
	the following criteria: 
	
	<list style="symbols">

	  <t>a limited number of &lt;ELI, EL&gt; pairs SHOULD be inserted in 
	  the SR-MPLS label stack;</t>
	  <t>the inserted positions SHOULD be whithin the ERLD of a maximize 
	  number of transit LSRs; </t>
	  <t>a minimum number of &lt;ELI, EL&gt; pairs SHOULD be inserted while
	  satisfying the above criteria.</t>
	</list>
	</t>
	
	<t>As described in <xref target="RFC8662"></xref> section 7, the ERLD value 
	is important for inserting ELI/EL and the ingress node need to evaluate the
	minimum ERLD value along the node segment path. But it will add complexity 
	in the ELI/EL insertion process. Moreover, the ingress node cannot find the
	minimum ERLD along the path and does not support the computation of the 
	minimum ERLD especilly in inter-domain scenarios. As the Figure 1 shown, in 
	SR-MPLS inter-domain scenario, the ingress node of the first domain could 
	not get the ERLD information of other nodes of other domains.</t>
   
   
   <figure title="Figure 1: Entropy Labels in SR-MPLS Inter-Domain Scenario" align="center">
         <artwork align="center"><![CDATA[
 

          +-----+                +-----+                 +-----+              
          |PCE-1|                |PCE-2|                 |PCE-3|            
          +--+--+                +--+--+                 +--+--+              
             |                      |                       |
    .........+..........   .........+..........    .........+...........
    .                  .   .                  .    .                   .
    .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
    .| A |-------| B |------ | C |------| X |-------| Y |------| Z  |  .
    .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
    .    SR-AS 1       .   .   SR-AS 2        .    .     SR-AS 3       .
    ....................   ....................    .....................			
	
	   ]]></artwork>
  <postamble></postamble>
 </figure>	
 
    <t>The PCEs could get the information of all nodes such as  Maximum SID 
	Depth (MSD) and ERLD through Interior Gateway Protocol (IGP) and can 
	compute the minimum ERLD along the end-to-end path. For example, 
	the ERLD value can be collected via IS-IS <xref target="I-D.ietf-isis-mpls-elc"></xref>, 
	OSPF<xref target="I-D.ietf-ospf-mpls-elc"></xref>. 
	<xref target="RFC8476"></xref> and <xref target="RFC8491"></xref> 
    provide examples of advertisement of the MSD.
	Moreover, the PCEs also can compute the Entropy Label Position (ELP)
	including the number and the places of the ELI/ELs. Then the ingress 
	nodes MAY be required to support the capabilities of inserting multiple 
	ELI/ELs and need to advertise the capabilities to the PCEs. </t>
	
	<t>This document proposes the extensions for PCE to perform the 
	computation of the end-to-end path as well as the positions of 
	entropy labels in SR-MPLS networks. The ingress nodes can directly
	insert the ELI/ELs based on the positions.</t>
   
   </section>
   <section title="PCEP Extensions">
   
   <section title="The OPEN Object">
   <t>As defined in <xref target="RFC8664"></xref>, PCEP speakers use SR 
   PCE Capability sub-TLV to exchange information about their SR capability
   when PST=1 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV carried 
   in Open object. This document defined a new flag (E-flag) for SR PCE 
   Capability sub-TLV as shown in Figure 2.</t>
   
   
   <figure title="Figure 2: E-flag in SR-PCE-CAPABILITY sub-TLV" align="center">
     <artwork align="center"><![CDATA[

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type=TBD11            |            Length=4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |   Flags |E|N|X|      MSD      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             
    ]]></artwork>
   <postamble></postamble>
   </figure> 
 
   <t> E (Entropy Label Configuration is supported) : A PCE sets this flag bit
   to 1 carried in Open message to indicate that it supports the computation
   of SR path with ELP information. A PCC sets this flag to 1 to indicate 
   that it supports the capability of inserting multiple ELI/EL pairs and 
   and supports the results of SR path with ELP from PCE.</t>
   </section>
    
  <section title="The LSP-EXTENDED-FLAG TLV">
  
  <t>The LSP Object is defined in Section 7.3 of <xref target="RFC8231"></xref>.  This document
   defiend a new flag (E-flag) for the LSP-EXTENDED-FLAG TLV carried in LSP
   Object as defined in <xref target="I-D.ietf-pce-lsp-extended-flags"></xref>. The format is 
   shown as Figure 3:</t>
  
  
  <figure title="Figure 3: E-flag in LSP-EXTENDED-FLAG TLV" align="center">
     <artwork align="center"><![CDATA[
   
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Type=TBD            |          Length               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                             |E|
    //                 LSP Extended Flags                          //
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             
    ]]></artwork>
   <postamble></postamble>
   </figure> 
   
   
   <t> E (Request for ELP Configuration) : If the bit is set to 1, it 
   indicates that the PCC requests PCE to compute the SR path with ELP 
   information. A PCE would also set this bit to 1 to indicate that 
   the ELP information is included by PCE and encoded in the PCRep, 
   PCUpd or PCInitiate message.</t>
   
   </section>

  
   <section title="The SR-ERO Object">
   
    <t>SR-ERO subobject is used for SR-TE path which consists of one or more
	SIDs as defined in <xref target="RFC8664"></xref>. This document defiend 
	a new flag (E-flag) for the SR-ERO subobject as Figure 4 shown: </t>
    
   <figure title="Figure 4: E-flag in SR-ERO subobject" align="center">
         <artwork align="center"><![CDATA[

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|   Type=36   |     Length    |  NT   |     Flags   |E|F|S|C|M|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         SID (optional)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                   NAI (variable, optional)                  //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	 
	
	   ]]></artwork>
  <postamble></postamble>
 </figure>	
 
    <t> E (ELP Configuration) : If this flag is set, it means that the 
	position after this SR-ERO subobject is the position to insert 
	&lt;ELI, EL&gt;, otherwise it cannot insert &lt;ELI, EL&gt; 
	after this segment.</t>

 
   </section>
   
   </section>
   
   <section title="Operations">
   
   <t>The SR path is initiated by PCE or PCC with PCReq, PCInitiated or PCUpd 
   messages and the E bit is set to 1 in LSP object to request the ELP configuration.
   The SR-TE path being recieved by PCC with SR-ERO segment list, for example, 
   &lt;S1, S2, S3, S4, S5, S6&gt;, especially S3 and S6 with E-flag set. It 
   indicates that two &lt;ELI, EL&gt; pairs MUST be inserted into the label 
   stack of the SR-TE forwarding entry, repectively after the label for S3 
   and label for S6. With EL information, the label stack for SR-MPLS
   would be &lt;label1, label2, label3, ELI, EL, label4, label5, label6, 
   ELI, EL&gt;.</t>
   </section>
   
    
   <section title="Security Considerations">
    <t>Procedures and protocol extensions defined in this document do not	
 	introduce any new security considerations beyond those already listed	
 	in <xref target="RFC8662"></xref> and <xref target="RFC8664"></xref>.</t>
   </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
    <t>The authors would like to thank Stephane Litkowski, Dhruv Dhody,
	Tarek Saad, Zhenbin Li and Jeff Tantsura for their review, 
	suggestions and comments to this document.</t>
	  
    </section>
	
	<section anchor="IANA" title="IANA Considerations">
	<section title="New SR PCE Capability Flag Registry">
	
	<t>SR PCE Capability TLV is defined in <xref target="RFC8664"></xref>,
    and the registry to manage the Flag field of the SR PCE Capability
    TLV is requested in <xref target="RFC8664"></xref>. IANA is requested to 
    make allocations from the registry, as follows: </t>
	
     <texttable anchor="table1">
     <ttcol align = 'center'> Value </ttcol>
     <ttcol align = 'center'> Name </ttcol>
     <ttcol align = 'center'> Reference </ttcol>
     <c> TBD11 </c>
     <c> Entropy Label Configuration is supported (E) </c>
     <c>[this document] </c>
     </texttable>
     </section>
	 
	 <section title="New LSP-EXTENDED-FLAG Flag Registry">
	
	<t><xref target="I-D.ietf-pce-lsp-extended-flags"></xref> defines the LSP-EXTENDED-FLAG TLV.
	IANA is requested to make allocations from the Flag field registry, as follows: </t>
	
     <texttable anchor="table2">
     <ttcol align = 'center'> Value </ttcol>
     <ttcol align = 'center'> Name </ttcol>
     <ttcol align = 'center'> Reference </ttcol>
     <c> TBD </c>
     <c> Request for ELP Configuration (E) </c>
     <c>[this document] </c>
     </texttable>
     </section>
	 
	 <section title="New SR-ERO Flag Registry">
	
	<t>SR-ERO subobject is defined in <xref target="RFC8664"></xref>,
    and the registry to manage the Flag field of SR-ERO is requested 
	in <xref target="RFC8664"></xref>. IANA is requested to make 
	allocations from the registry, as follows: </t>
	
     <texttable anchor="table3">
     <ttcol align = 'center'> Value </ttcol>
     <ttcol align = 'center'> Name </ttcol>
     <ttcol align = 'center'> Reference </ttcol>
     <c> 36 </c>
     <c> ELP Configuration (E) </c>
     <c>[this document] </c>
     </texttable>
     </section>
	 
	 
    </section>
	
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
  
    <references title="Normative References">
    <?rfc include='reference.RFC.2119'?>
	<?rfc include='reference.RFC.5440'?>
	<?rfc include='reference.RFC.8174'?>
	<?rfc include='reference.RFC.8231'?>
	<?rfc include='reference.RFC.8281'?>
	<?rfc include='reference.RFC.8623'?>
	<?rfc include='reference.RFC.6790'?>
	<?rfc include='reference.RFC.8660'?>
	<?rfc include='reference.RFC.8664'?>
    <?rfc include='reference.RFC.8662'?>
    <?rfc include='reference.RFC.8476'?>
	<?rfc include='reference.RFC.8491'?>
	<?rfc include='reference.I-D.ietf-isis-mpls-elc'?>
	<?rfc include='reference.I-D.ietf-ospf-mpls-elc'?>
	<?rfc include='reference.I-D.ietf-pce-lsp-extended-flags'?>
	<?rfc include='reference.I-D.zhou-idr-bgp-srmpls-elp'?>
	
    </references>
        
  </back>
</rfc>
