<?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-lp-idr-bgp-ls-sr-policy-supplement-00"
      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-LS SR Policy">Supplement of BGP-LS Distribution for SR Policies and State</title>
    <seriesInfo name="Internet-Draft" value="draft-lp-idr-bgp-ls-sr-policy-supplement-00"/>


   <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>Routing</area>
    <workgroup>IDR 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. -->

    <keyword>SR Policy</keyword>
    <keyword>BGP-LS</keyword>
    <keyword>Segment List</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 supplements some additional information of the segment list in the BGP-LS advertisement for SR Policy state information .</t> 

    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  

<t>SR Policy architecture details are specified in <xref target="RFC9256"></xref>.  An SR Policy comprises one or more candidate paths (CP) of which at a given time one and only one may be active. Each CP in turn may have one or more SID-List of which one or more may be active; when multiple are active then traffic is load balanced over them.</t>


<t><xref target="I-D.ietf-pce-multipath"></xref> proposes extensions to PCEP to specify the protection relationship among segment lists within the candidate path. There would be segment lists in the CP acting as backup for one or more primary segment lists, the backup lists only carry rerouted traffic after the protected path fails.</t>
<t><xref target="I-D.ietf-idr-bgp-ls-sr-policy"></xref> describes a mechanism to collect the SR policy information that is locally available in a node and advertise it into BGP Link State (BGP-LS) updates. Various TLVs are defined to enable the headend to report the state at the SR Policy CP level. For example, there's a B Flag in the SR Candidate Path State TLV indicating the CP is in an administrative shut state when set.</t> 

<t>Currently, a few segment list-related information is not included in <xref target="I-D.ietf-idr-bgp-ls-sr-policy"></xref>. One is the information to indicate that the segment list is a backup path as described in <xref target="I-D.ietf-pce-multipath"></xref>. And the segment list may be shut by the administrator, this information may also needed and reported via BGP-LS.</t>
<t> This document supplements some additional information of the segment list in the BGP-LS advertisement for SR Policy state information .</t>  
 
	  
      <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> <xref target="RFC8174" format="default"></xref> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
	
	
<section numbered="true" toc="default">
<name>BGP-LS Extensions for Distributing Segment List States</name>
	<t>SR Segment List TLV is defined in <xref target="I-D.ietf-idr-bgp-ls-sr-policy"></xref> to to report the SID-List(s) of a candidate path.As show in Figure 1,this document introduces two new flags in the flag field of SR Segment List TLV, where,</t>
		<figure>
		<name>Flag Field of SR Segment List TLV</name>
			<artwork align="center" ><![CDATA[
       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|E|C|V|R|F|A|T|M|S|B|         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ]]></artwork>		   
		</figure>
		

	<ul spacing="normal">	
        <li>S-Flag: Indicates the segment list is in administrative shut state when set.</li>
		<li>B-Flag: Indicates the segment list is a backup path described in <xref target="I-D.ietf-pce-multipath"></xref> when set, otherwise it is the primary path.</li>
     </ul>


	
</section>	

	
<section numbered="true" toc="default">
	<name>IANA Considerations</name>
	
	<t>This document requests bit 9 and bit 10 in the flag field of  "SR Segment List TLV" <xref target="I-D.ietf-idr-bgp-ls-sr-policy"></xref> under the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry.</t>

        <artwork align="left"><![CDATA[
       Bit     Description                                Reference
      ------------------------------------------------------------------
        9     Administrative Shut State Flag(S-Flag)      This document
       10     Backup Path State Flag(B-Flag)              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-bgp-ls-sr-policy"></xref>.</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.8174.xml"?>			
		<?rfc include="reference.I-D.ietf-idr-bgp-ls-sr-policy.xml"?>
      </references>
      <references>
        <name>Informative References</name>
		<?rfc include="reference.RFC.8402.xml"?>
		<?rfc include="reference.RFC.9256.xml"?>
		<?rfc include="reference.I-D.ietf-pce-multipath.xml"?>
      </references>
    </references>


 </back>
</rfc>
