<?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-sr-path-protection-05"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

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

 <front>


   <title abbrev="Segment List Protection">BGP Extensions of SR Policy for Segment List Protection</title>
    <seriesInfo name="Internet-Draft" value="draft-lp-idr-sr-path-protection-05"/>


   <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>	

   <author fullname="Changwang Lin" surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>linchangwang.04414@h3c.com</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>


    <keyword>SR Policy</keyword>
    <keyword>Path Protection</keyword>
    <keyword>Segment List</keyword>


   <abstract>
	<t>
This document proposes extensions of BGP in order to provide protection information for segment lists when delivering SR policy via BGP.
	 </t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
	  
	<t>Segment Routing <xref target="RFC8402"></xref> allows a headend node to steer a packet flow along any path. <xref target="RFC9256" format="default"></xref> details the concept of SR Policy and steering into an SR Policy. An SR Policy is a set of candidate paths, each consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. </t>
  <t>Candidate path can be used for path protection, that is, the lower preference candidate path may be designated as the backup for a specific or all (active) candidate path(s). Backup candidate path provide protection only when all the segment lists in the active CP are invalid.If a candidate path is associated with a set of Segment-Lists, each Segment-List is associated with weight for weighted load balancing. </t>

  <t>The protection mechanism for SR Policy is not flexible enough. For example, there're two active segment lists(SL1, SL2) in the primary candidate path CP1, SL1 and SL2 can together carry 80 Gbps. If SL1 fails, CP1 are still the primary path, but the bandwith of CP1 is probably not enough. If there's a backup segment list for SL1, e.g, SL3, in CP1, traffic will be load-balanced between SL3 and SL2 after SL1 fails.</t>    

  <t>The pcep extensions for segment list identification and protection relationship among segment lists specification are proposed in <xref target="I-D.ietf-pce-multipath"></xref>. </t> 
  <t><xref target="I-D.ietf-idr-segment-routing-te-policy"></xref> specifies BGP extensions for the advertisement of SR Policy. <xref target="I-D.lin-idr-sr-policy-seglist-id"></xref> defines extensions to BGP SR Policy to specify the identifier of segment list.</t>
  <t>This document proposes extensions of BGP in order to provide the protection information of segment lists when delivering SR policy via BGP. </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 Extensions for Advertising Segment List</name>
		<section numbered="true" toc="default">
			<name>Extensions of Segment List sub-TLV</name>
		<t>Segment List sub-TLV is introduced in <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref> and it includes the elements of the paths (i.e., segments).</t>
		<t>This document introduces a one-bit flag in the RESERVED field, where, </t>
		
		<figure anchor="flag">
		<name>B-Flag in Segment List sub-TLV</name>
        <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            |B|  RESERVED   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                           sub-TLVs                          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  
           ]]></artwork>
      </figure>
	  	<ul spacing="normal">
        <li>B-Flag(Backup Flag): One bit. If set, indicates a pure backup path. This is a segment list that only carries rerouted traffic after the protected segment list fails. If this flag is not set, it indicates that the segment list acts as the active member in the candidate path that carries normal traffic.</li>
		</ul>

		<t>Using segment lists for path protection can be compatible with using candidate paths. When a path fails, the backup segment list within the same candidate path is used preferentially for path protection. If the backup list is also invalid, then other candidate path can be enabled for protection.</t>

		</section>		
		
		<section numbered="true" toc="default">
			<name>List Protection Sub-TLV</name>	
		<t>This document introduces a new sub-sub-tlv of Segment List sub-TLV, where, </t>
		<figure>
		<name>List Protection Sub-TLV</name>
        <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     |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Backup  List ID 1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ...                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
   |                    Backup  List ID N                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	  
           ]]></artwork>
      </figure>
		<ul spacing="normal">
        <li>Type: 1 octet. TBD.</li>
		<li>Length: 1 octet, specifies the length of the value field not including Type and Length fields.</li>
		<li>RESERVED: 2 octet of reserved bits. SHOULD be unset on transmission and MUST be ignored on receipt.</li>
		<li>Backup List ID: 4 octet of ID for the back up segment list, the segment list id is delivered in Segment List ID Sub-TLV as define in <xref target="I-D.lin-idr-sr-policy-seglist-id"></xref>. If there're multiple backup paths, the list ID of each path should be included in the TLV.</li>
		</ul>
		<t>As defined in <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref>, the SR Policy encoding structure is as follows:</t>
        <artwork align="left"><![CDATA[
      SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encaps Attribute (23)
            Tunnel Type: SR Policy
                Binding SID
                Preference
                Priority
                Policy Name
                Explicit NULL Label Policy (ENLP)
                Segment List
                    Weight
                    Segment
                    Segment
                    ...
                Segment List
                    ...
                ...
	  
           ]]></artwork>

		<t>The new SR Policy encoding structure with List Protection sub-TLV is shown as below:</t>
        <artwork align="left"><![CDATA[
	SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
	Attributes:
       Tunnel Encaps Attribute (23)
         Tunnel Type: SR Policy
             Binding SID
             SRv6 Binding SID
             Preference
             Priority
             Policy Name
             Policy Candidate Path Name
             Explicit NULL Label Policy (ENLP)
             Segment List
                 List Protection
                 Weight
                 Segment
                 Segment
                 ...
             Segment List
                 ...
             ...
	  
           ]]></artwork>		
	
		</section>
		
</section>	  
	
    	

	
<section numbered="true" toc="default">
	<name>IANA Considerations</name>

	<section numbered="true" toc="default">
	<name>New Registry: Flag Field of Segment List sub-TLV</name>	
	<t>This document introduces a one-bit flag field in the Segment List sub-TLV <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref> for the Backup Flag (B-Flag).</t>
   
	</section>

	
	<section numbered="true" toc="default">
	<name>Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs</name>

	<t>This document defines a new sub-TLV in the registry "SR Policy List Sub-TLVs" <xref target="I-D.ietf-idr-segment-routing-te-policy"></xref> to be assigned by IANA:</t>
	
        <artwork align="left"><![CDATA[
        Codepoint   Description                           Reference
        -------------------------------------------------------------
        TBD         List Protection Sub-TLV               This document
           ]]></artwork>


	</section>		
	   
	
</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>	
	
	
  </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-segment-routing-te-policy.xml"?>
		<?rfc include="reference.I-D.lin-idr-sr-policy-seglist-id.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>
