<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-peng-idr-segment-routing-te-policy-attr-04"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

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

 <front>


   <title abbrev="BGP SID Algo">Advertising SID Algorithm Information in BGP</title>
    <seriesInfo name="Internet-Draft" value="draft-peng-idr-segment-routing-te-policy-attr-04"/>


   <author fullname="Yao Liu" surname="Liu">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>liu.yao71@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
	
	 <author fullname="Shaofu Peng" surname="Peng">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>peng.shaofu@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
    <date year="2023"/>

   <!-- Meta-data Declarations -->

   <area>Internet</area>
    <workgroup>IDR</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. -->

   <keyword>Algorithm</keyword>
   <keyword>SR Policy</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
    <t>
This document proposes extensions of BGP and defines new Segment Types to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP.
    </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
    <t>Segment Routing (SR) <xref target="RFC8402"></xref> allows a headend node to steer a packet flow along any path. <xref target="RFC9256" format="default"></xref> details the concepts of SR Policy and steering into an SR Policy. These apply equally to the MPLS and IPv6 data plane instantiations of Segment Routing with their respective representations of segments as SR-MPLS SID and SRv6 SID as described in <xref target="RFC8402"></xref>.</t>
	<t><xref target="I-D.ietf-idr-segment-routing-te-policy"></xref> specifies the way to use BGP to distribute one or more of the candidate paths of an SR Policy to the headend of that policy. It defines a new BGP address family (SAFI), i.e., SR Policy SAFI NLRI. In UPDATE messages of that address family, the NLRI identifies an SR Policy Candidate Path, and the attributes encode the segment lists and other details of that SR Policy Candidate Path. 11 Segment Types (from A to K) are defined to encode SR-MPLS or SRv6 segments.</t>
	
	<t>As specified in <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref>, the SR algorithm can be optionally specified for Segment Types C(IPv4 Node and SID), D(IPv6 Node and SID for SR-MPLS), I(IPv6 Node and SID for SRv6), J(IPv6 Node, index for remote and local pair, and SID for SRv6), and K(IPv6 Local/Remote addresses and SID for SRv6). That is, currently the algorithm can be carried along with SR-MPLS prefix SID, SRv6 prefix SID and SRv6 adjacency SID when delivering SR Policy via BGP.</t>


	<t><xref target="I-D.ietf-lsr-algorithm-related-adjacency-sid"></xref> complements that, besides the SR-MPLS prefix SID, the algorithm can be also included as part of an SR-MPLS Adjacency-SID advertisement, in scenarios where multiple algorithm share the same link resource. In this case, an SR-MPLS Policy advertised to the headend may also contain algorithm specific Adjacency-SID.</t>

	<t>This document proposes extensions of BGP and defines new Segment Types to provide algorithm information for SR-MPLS Adjacency-SIDs when delivering SR Policy via BGP.</t>

	
	   
    </section>
	

	    <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119" format="default"></xref>.</t>
      </section>
	  
<section numbered="true" toc="default">
<name>New Segment Types for SR-MPLS Adjacency with optional Algorithm</name>		  

	<t>This section defines four new Segment Sub-TLVs of Segment List Sub-TLV to provide algorithm information for SR-MPLS Adjacency-SIDs.</t>
	<t>The processing procedures for SID with algorithm specified in <xref target="RFC9256" format="default"></xref> and <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref> are still applicable for the new segment types. 
	When the algorithm is not specified for the SID types above which optionally allow for it, the headend SHOULD use the Strict Shortest Path algorithm if available; otherwise, it SHOULD use the default Shortest Path algorithm.
	</t>	  
	  
	<section numbered="true" toc="default">
	<name>Type M: IPv4 Address and Local Interface ID with optional Algorithm</name>
	<t>The Type M Segment Sub-TLV is similar with existed Type E Segment Sub-TLV, it also encodes an IPv4 node address, a local interface Identifier (Local Interface ID) and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:</t>
        <artwork align="center" name=""><![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     |  SR Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Local Interface ID (4 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 IPv4 Node Address (4 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
	<t>Where:</t>
	<t>Type: TBD1</t>
	<t>SR Algorithm: 1 octet specifying SR Algorithm as described in <xref target="RFC8402" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-3.1.1" derivedContent="RFC8402"/>) when A-Flag as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>) is present. SR Algorithm is used by SRPM as described in <xref target="RFC9256" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9256#section-4" derivedContent="RFC9256"/>). When A-Flag is not encoded, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.</t>
	<t>Other fields have the same meaning as the Type E Segment Sub-TLV in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.5" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.5" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>), where:</t>
	<t>Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets.  The value MUST be 14 when the SR-MPLS SID is present else it MUST be 10.</t>

	<t>Flags: 1 octet of flags as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>


	<t>Local Interface ID: 4 octets of interface index as defined in <xref target="RFC8664" format="default"></xref>.</t>

	<t>IPv4 Node Address: a 4-octet IPv4 address representing a node.</t>

	<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S and TTL as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.1" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>


	
	
	</section>	  
	  
	<section numbered="true" toc="default">
	<name>Type N: IPv4 Addresses for link endpoints as Local, Remote pair with optional Algorithm</name>
	<t>The Type N Segment Sub-TLV is similar with existed Type F Segment Sub-TLV, it also encodes an adjacency local address, an adjacency remote address and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:</t>
        <artwork align="center" name=""><![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     |  SR Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Local IPv4 Address (4 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Remote IPv4 Address  (4 octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
	<t>Where:</t>
	<t>Type: TBD2</t>
	<t>SR Algorithm: 1 octet specifying SR Algorithm as described in <xref target="RFC8402" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-3.1.1" derivedContent="RFC8402"/>) when A-Flag as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>) is present. SR Algorithm is used by SRPM as described in <xref target="RFC9256" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9256#section-4" derivedContent="RFC9256"/>). When A-Flag is not encoded, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.</t>
	<t>Other fields have the same meaning as the Type F Segment Sub-TLV <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.6" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.6" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>), where:</t>	
	
	<t>Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets.  The value MUST be 14 when the SR-MPLS SID is present else it MUST be 10.</t>

	<t>Flags: 1 octet of flags as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>

<t>Local IPv4 Address: a 4-octet IPv4 address representing the local link address of the node.</t>

<t>Remote IPv4 Address: a 4-octet IPv4 address representing the link address of the neighbor node.</t>

<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S and TTL as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.1" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>
	
	
	
	
	</section>	
	  
	<section numbered="true" toc="default">
	<name>Type O: IPv6 Prefix and Interface ID for link endpoints as Local, Remote pair, with optional Algorithm for SR-MPLS</name>
	<t>The Type O Segment Sub-TLV is similar with existed Type G Segment Sub-TLV, it also encodes an IPv6 Link Local adjacency with IPv6 local node address, a local interface identifier (Local Interface ID), IPv6 remote node address , a remote interface identifier (Remote Interface ID) and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:</t>
        <artwork align="center" name=""><![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     |  SR Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Local Interface ID (4 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                IPv6 Local Node Address (16 octets)          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Remote Interface ID (4 octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                IPv6 Remote Node Address (16 octets)         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
	<t>Where:</t>
	<t>Type: TBD3</t>
	<t>SR Algorithm: 1 octet specifying SR Algorithm as described in <xref target="RFC8402" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-3.1.1" derivedContent="RFC8402"/>) when A-Flag as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>) is present. SR Algorithm is used by SRPM as described in <xref target="RFC9256" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9256#section-4" derivedContent="RFC9256"/>). When A-Flag is not encoded, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.</t>
	<t>Other fields have the same meaning as the Type G Segment Sub-TLV <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.7" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.7" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>), where:</t>

	<t>Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets.  The value MUST be 14 when the SR-MPLS SID is present else it MUST be 10.</t>

	<t>Flags: 1 octet of flags as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>

   <t>Local Interface ID: 4 octets of interface index as defined in <xref target="RFC8402"></xref>.</t>

	<t>IPv6 Local Node Address: a 16-octet IPv6 address representing the node.</t>

	<t>Remote Interface ID: 4 octets of interface index as defined in <xref target="RFC8402"></xref>.  The value MAY be set to zero when the local node address and interface identifiers are sufficient to describe the link.</t>

	<t>IPv6 Remote Node Address: a 16-octet IPv6 address.  The value MAY be set to zero when the local node address and interface identifiers are sufficient to describe the link.</t>

	<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S and TTL as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.1" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>
	
	</section>		  
	  
	  
	<section numbered="true" toc="default">
	<name>Type P: IPv6 Addresses for link endpoints as Local, Remote pair, with optional Algorithm for SR-MPLS</name>
	<t>The Type P Segment Sub-TLV is similar with existed Type H Segment Sub-TLV, it also encodes an adjacency local address, an adjacency remote address and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:</t>
        <artwork align="center" name=""><![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     |  SR Algorithm |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //               Local IPv6 Address (16 octets)                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //               Remote IPv6 Address  (16 octets)              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>
	<t>Where:</t>
	<t>Type: TBD4</t>
	<t>SR Algorithm: 1 octet specifying SR Algorithm as described in <xref target="RFC8402" sectionFormat="of" section="3.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8402#section-3.1.1" derivedContent="RFC8402"/>) when A-Flag as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>) is present. SR Algorithm is used by SRPM as described in <xref target="RFC9256" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9256#section-4" derivedContent="RFC9256"/>). When A-Flag is not encoded, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.</t>
	<t>Other fields have the same meaning as the Type H Segment Sub-TLV <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.8" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.8" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>), where:</t>
	<t>Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets.  The value MUST be 14 when the SR-MPLS SID is present else it MUST be 10.</t>

	<t>Flags: 1 octet of flags as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.12" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.12" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>

   <t>Local IPv6 Address: a 16-octet IPv6 address representing the local link address of the node.</t>

   <t>Remote IPv6 Address: a 16-octet IPv6 address representing the link address of the neighbor node.</t>
	  
	<t>SR-MPLS SID: optional, 4-octet field containing label, TC, S and TTL as defined in <xref target="I-D.ietf-idr-segment-routing-te-policy" sectionFormat="of" section="2.4.4.2.1" format="default" derivedLink="https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy#section-2.4.4.2.1" derivedContent="I-D.ietf-idr-segment-routing-te-policy"/>).</t>	  

	
	</section>		  
	  

</section>	  
	

	

	
<section numbered="true" toc="default">
	<name>IANA Considerations</name>
	<t>This document requests codepoint allocations for new Segment Sub-TLVs in the "SR Policy List Sub-TLVs" registry.</t>
        <artwork align="center" name=""><![CDATA[
Value  Description                                          Reference
------------------------------------------------------------------------
TBD1  Segment Type M sub-TLV                               This document
TBD2  Segment Type N sub-TLV                               This document
TBD3  Segment Type O sub-TLV                               This document
TBD4  Segment Type P sub-TLV                               This document   
           ]]></artwork>
	</section>	

<section numbered="true" toc="default">
	<name>Security Considerations</name>
    <t>Procedures and protocol extensions defined in this document do not affect the security considerations discussed in <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref>.</t>
</section>	

<section numbered="true" toc="default">
	<name>Acknowledgement</name>
    <t>The authors would like to thank Ketan Talaulikar for his comments and suggestions.</t>
</section>	
	
	
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
		<?rfc include="reference.RFC.2119.xml"?>
		<?rfc include="reference.RFC.9256.xml"?>
		<?rfc include="reference.I-D.ietf-idr-segment-routing-te-policy.xml"?>	
		<?rfc include="reference.RFC.8664.xml"?>

	  
      </references>
      <references>
        <name>Informative References</name>
	<?rfc include="reference.RFC.8200.xml"?>
	<?rfc include="reference.RFC.8402.xml"?>
	<?rfc include="reference.RFC.8754.xml"?>
	<?rfc include="reference.RFC.8660.xml"?>
	<?rfc include="reference.RFC.8665.xml"?>
	<?rfc include="reference.RFC.8666.xml"?>
	<?rfc include="reference.RFC.8667.xml"?>
	<?rfc include="reference.I-D.ietf-lsr-algorithm-related-adjacency-sid.xml"?>		
      </references>
    </references>


 </back>
</rfc>
