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

<?xml-model href="rfc7991bis.rnc"?>

<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> --> 
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->

<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->

<rfc category="std"
    xmlns:xi="http://www.w3.org/2001/XInclude"
    docName="draft-all-pce-srv6-policy-sid-list-optimization-00"
    consensus="true"
    submissionType="IETF"
    ipr="trust200902"
    tocInclude="true"
    tocDepth="4"
    symRefs="true"
    sortRefs="true">

 <!-- ***** FRONT MATTER ***** -->

 <front>
   <!-- The abbreviated title is used in the page header - it is only necessary if the 
        full title is longer than 39 characters -->
    <title abbrev="PCEP extensions for SRv6 Policy SID List Optimization">
	    Path Computation Element Communication Protocol (PCEP) 
    extensions for SRv6 Policy SID List Optimization </title>
    <seriesInfo name="Internet-Draft" value="draft-all-pce-srv6-policy-sid-list-optimization-00"/>

   <author fullname="Zafar Ali" initials="Z." surname="Ali">
     <organization>Cisco Systems, Inc.</organization>
     <address>
       <email>zali@cisco.com</email>
     </address>
   </author>

   <author fullname="Changwang Lin" initials="C." surname="Lin">
     <organization>New H3C Technologies</organization>
     <address>
       <email>linchangwang.04414@h3c.com</email>
     </address>
   </author>

   <author fullname="Yisong Liu" initials="Y." surname="Liu">
     <organization>China Mobile</organization>
     <address>
       <email>liuyisong@chinamobile.com</email>
     </address>
   </author>
   
            <author fullname="Rajesh M Venkateswaran" initials="R." surname="Venkateswaran">
     <organization>Cisco Systems, Inc.</organization>
     <address>
       <email>melarco@cisco.com</email>
     </address>
   </author>

            <author fullname="Ran Chen" initials="R." surname="Chen">
     <organization>ZTE Corporation</organization>
     <address>
       <email>chen.ran@zte.com.cn</email>
     </address>
   </author>
 
     <author fullname="Cheng Li" initials="C." surname="Li">
     <organization>Huawei Technologies</organization>
     <address>
       <email>c.l@huawei.com</email>
     </address>
   </author>
   
       <author fullname="Yuanxiang Qiu" initials="Y." surname="Qiu">
     <organization>New H3C Technologies</organization>
     <address>
       <email>qiuyuanxiang@h3c.com</email>
     </address>
   </author>
    
    <author fullname="Samuel Sidor" initials="S." surname="Sidor">
     <organization> Cisco Systems, Inc.</organization>
     <address>
       <email>ssidor@cisco.com</email>
     </address>
   </author>


        
   <date year="2025" />

   <!-- Meta-data Declarations -->
   <area>Routing</area>
   <workgroup>PCE Working Group</workgroup>

   <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions. 
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->


   <abstract>
<t>In some use cases, an SRv6 policy's SID list ends with the policy endpoint's node SID, 
and the traffic steered (over policy) already ensures that it is taken to the policy endpoint. 
In such cases, the SID list can be optimized by excluding the endpoint Node SID when 
installing the policy. This draft specifies a PCEP extension to indicate whether the endpoint's 
node SID needs to be included or excluded when installing the SRv6 Policy.</t>
   
   </abstract>

   <note 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 target="RFC8174"/> when,
      and only when, they appear in all capitals, as shown here. 
     </t>
   </note>

 </front>

 <middle>
  <section anchor="intro" title="Introduction">
  <t> 
  Segment Routing (SR) <xref target="RFC8402"/> allows a node to steer a packet flow along any path.  
  A Segment Routing Policy (SR Policy) <xref target="RFC8402"/> is an ordered list of 
  segments that represent a source-routed policy. 
  The headend node is said to steer a flow into an SR Policy.  
  The packets steered into an SR Policy have an ordered list of segments associated 
  with that SR Policy written into them. 
  Segment Routing Policy Architecture <xref target="RFC9256"/> updates <xref target="RFC8402"/> as 
  it details the concepts of SR Policy and steering into an SR Policy. <xref target="RFC8986"/>
   describes the representation and processing of this ordered 
  list of segments for Segment Routing over IPv6 (SRv6). 
  <xref target="RFC9603"/> specifies PCEP extensions to support SR for the IPv6 data plane. 

  </t>

  <t> 
  
  A PCE computes the SRv6 TE Policy SID list from the headend to the endpoint. 
  The computed SID list may end with the policy endpoint's Node SID or the penultimate 
  hop adjacency SID. If the computed SID list ends with the policy endpoint's node SID 
  and the overlay SID in the steered traffic (over policy) already ensures that the 
  traffic is taken to the policy endpoint with the same intent, the SRv6 
  policy endpoint device needs to process back-to-back local node SIDs. Examples of overlay 
  SID containing the local node SID are a service SID, a binding SID for transit 
  policies, an EPE SID, etc. From a compression efficiency viewpoint, carrying 
  back-to-back end-point node SID is inefficient. The SID list in the packet 
  can be optimized by excluding the end-point node SID when installing the policy. 
  End-point node SID exclusion improves the compression efficiency and makes packet 
  processing more efficient for the policy endpoint. 

  </t>
  
  <t>
  
  Excluding the policy endpoint's node SID is possible in most use cases, 
  but not all. For example, if the SRv6 policy is used to carry MPLS traffic, 
  as described in [I-D.draft-agrawal-spring-srv6-mpls-interworking], 
  it is not possible to exclude the policy endpoint's node SID. Specifically, 
  the endpoint's node SID inclusion or exclusion is a policy attribute. This 
  draft specifies a PCEP extension to include or exclude the node SID when 
  installing the SRv6 Policy. 
  
  </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&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/> when,
      and only when, they appear in all capitals, as shown here. 
     </t>
    </section>
 
     <section anchor="terminology" title="Terminology">
        <t>
            This document uses the following terms defined in <xref target="RFC5440"/>: PCC, PCE, PCEP, PCEP Peer.
        </t>
        <t>
            SR: Segment Routing.
        </t>
        <t>
            SID: Segment Identifier.
        </t>
         <t>
            SRv6: Segment Routing over IPv6 data plane.
        </t>       
        
  </section>
  
 <section title="Overview of PCEP Extensions">

  <section title="New TLV in the SRPA Object">
	  <t> 
		  The draft specifies a new SRPOLICY-POL-ATTRIBUTE TLV for the SR Policy Association object defined in 
		  [I-D.draft-ietf-pce-segment-routing-policy-cp]. The SRPOLICY-POL-ATTRIBUTE TLV is optional. 
	  </t>
	  
	  <figure align="left" anchor="TLV" title="SRPOLICY-POL-ATTRIBUTE TLV">
        <artwork align="left"><![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              |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                             Flags                           |I|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>

	 <t> 
		 
    <ul>
       <li> 
       Type: TBD1 for "SRPOLICY-POL-ATTRIBUTE" TLV.
        </li>
       <li> 
       Length: 4. 
        </li> 
       <li> 
       Flags: The unassigned bits in the Flag octet MUST be set to zero upon transmission and MUST be ignored upon receipt.
        </li> 
             
       </ul>
	</t>
	</section>
	
	<section title="A New flag in the SRPOLICY-POL-ATTRIBUTE TLV">
	<t> 
	This document specifies I-flag (endpoint node SID Inclusion flag) bit in the Flags field of 
	"SRPOLICY-POL-ATTRIBUTE" TLV specified in this document. 
	The flag is applicable only to SR policies with SRv6 data plane. 
	The flag MUST be ignored for SR policies with SR-MPLS data planee.
	</t>
	 
	 <t> 
	 I (endpoint node SID Inclusion) - 1 bit (Bit Position TBD2): 
		 
    <ul>
       <li> 
       If set to 1, the endpoint node SID MUST be included when installing 
       the SRv6 Policy SID list(s) used to carry the data traffic.
        </li>
       <li> 
       If set to 0, the endpoint node SID MUST NOT be included when installing 
       the SRv6 Policy SID list(s) used to carry the data traffic.
        </li>        
       </ul>
	</t>

	 </section> 

  <section title="New flag in SRv6-PCE-CAPABILITY sub-TLV">
	 <t>
	 I-flag (endpoint node SID Inclusion capability flag) is proposed in
   the SRv6-PCE-CAPABILITY sub-TLV defined in [RFC9603].  The bit
   position for the flag in the SRv6 Capability Flag Field registry is
   to be defined by IANA.
	 </t>
	 
	 <t> 
	 I (endpoint node SID Inclusion capability flag) - 1 bit (Bit Position TBD3): 
		 
    <ul>
       <li> 
       If set to 1, it indicates support for the I-flag  
       in the SRPOLICY-POL-ATTRIBUTE TLV.
        </li>
       </ul>
	</t>
  
	 </section> 
 
	 </section> 
	 
	 <section title="Operation">
		 <t>
		 
		 A PCEP speaker indicates its ability to support I-flag in the Flags field of the SRPOLICY-POL-ATTRIBUTE 
		 TLV during the PCEP initialization phase by setting the I-flag in the 
		 SRv6-PCE-CAPABILITY sub-TLV in the Open message. 
		 
		 </t>
		 <t>
		 A PCEP peer indicates the 
		 inclusion or exclusion of the endpoint's Node SID in I-flag in 
		 the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV.
		 </t>
		 
		<t>	 
			 A PCEP peer MUST NOT set the I-flag flag if capability was not advertised by both peers.
		</t>

		 <t>
			If the PCEP peers are capable of supporting the I-flag and the I-flag  
			in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV is set, the PCC MUST include 
			the endpoint node SID when installing the SRv6 Policy sid
   			list(s) used to carry data traffic.

			 </t>			 

		 <t>
			If the PCEP peers are capable of supporting the I-flag and the I-flag  
			in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV is not set, the PCC MUST NOT include 
			the endpoint node SID when installing the SRv6 Policy sid
   			list(s) used to carry data traffic. 
			 </t>			 			 

		<t>
		I-flag value in the Flags field of the SRPOLICY-POL-ATTRIBUTE TLV MUST NOT change for a given 
		SRv6 Policy Candidate Path during its lifetime. 
		</t>
		
		 <t>
			Local policy at PCC MAY override the I-flag. 
			 </t>
		
		 <t>
			PCE ignores the I-flag received from the PCC when computing the path 
			and computes the SRv6 Policy SID list from the headend to the endpoint. 
			PCE MAY use the I-flag value for debugging purposes. 
			 </t>

		 </section>
		 
	 <section title="Backward compatibility">
		 <t>
		 If at least one PCEP peer is not capable of supporting the I-flag, 
		 the endpoint Node SID inclusion/exclusion SHOULD be set based on local 
		 policy at the PCC. 
			 
		 </t>
		 
		 </section> 
     
    <section title="Security Considerations">

		 <t>
			 
			    
   <xref target="RFC8754"/> defines the notion of an SR domain and use of SRH within
   the SR domain. Procedures for securing an SR domain are defined the
   section 5.1 and section 7 of <xref target="RFC8754"/>. 
   This document does not impose any additional security challenges to
   be considered beyond security threats described in <xref target="RFC8754"/>,
   <xref target="RFC8679"/> and <xref target="RFC8986"/>. 

		 </t>

    </section>

    <section anchor="iana" title="IANA Considerations">
		 <t>
			TBA
		 </t>      
    </section>

</middle>

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

<back>
    <!-- References split into informative and normative -->
    <references title="Normative References">
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9603.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://www.rfc-editor.org/refs/bibxml/reference.RFC.8679.xml"/>
        
    </references>

    <references title="Informative References">

    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t> The authors would like to thank Ketan Talaulikar   
      for the review comments. </t>
    </section>
    
</back>
</rfc>

