<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtgwg-srv6-egress-protection-11"
     ipr="trust200902">
  <front>
    <title abbrev="Egress Protection">SRv6 Path Egress Protection</title>

    <author fullname="Zhibo Hu" initials="Z. " surname="Hu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>huzhibo@huawei.com</email>
      </address>
    </author>

    <author fullname="Huaimo Chen" initials="H" surname="Chen">
      <organization>Futurewei</organization>

      <address>
        <postal>
          <street/>

          <city>Boston, MA</city>

          <region/>

          <code/>

          <country>USA</country>
        </postal>

        <email>Huaimo.chen@futurewei.com</email>
      </address>
    </author>
<!--
    <author fullname="Huanan Chen" initials="H. " surname="Chen">
      <organization>China Telecom</organization>

      <address>
        <postal>
          <street>109, West Zhongshan Road, Tianhe District</street>

          <city>Guangzhou</city>

          <code>510000</code>

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

        <email>chenhn8.gd@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Peng Wu" initials="P. " surname="Wu">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>Huawei Bld., No.156 Beiqing Rd.</street>

          <city>Beijing</city>

          <code>100095</code>

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

        <email>baggio.wupeng@huawei.com</email>
      </address>
    </author>
-->
    <author fullname="Mehmet Toy" initials="M" surname="Toy">
      <organization>Verizon</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

          <country>USA</country>
        </postal>

        <email>mehmet.toy@verizon.com</email>
      </address>
    </author>

    <author fullname="Chang Cao" initials="C" surname="Cao">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

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

        <email>caoc15@chinaunicom.cn</email>
      </address>
    </author>

    <author fullname="Tao He" initials="T" surname="He">
      <organization>China Unicom</organization>

      <address>
        <postal>
          <street/>

          <city/>

          <region/>

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

        <email>het21@chinaunicom.cn</email>
      </address>
    </author>

 <!--
    <author fullname="Lei Liu" initials="L" surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>USA</country>
        </postal>

        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

   <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>IBM Corporation</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Chris Bowers" initials="C. " surname="Bowers">
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street>1194 N. Mathilda Ave.</street>
          <city>Sunnyvale, CA</city>
          <code>94089</code>
          <country>USA</country>
        </postal>
        <email>cbowers@juniper.net</email>
      </address>
    </author>
-->

    <date year="2023"/>

    <abstract>
      <t>This document describes protocol extensions for protecting the egress
      node of a Segment Routing for IPv6 (SRv6) path or tunnel.</t>

      <t/>
    </abstract>

    <note title="Requirements Language">
      <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">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <!-- <xref target="I-D.hu-rtgwg-sr-proxy-forwarding"/>. -->

      <t>The fast protection of a transit node of a Segment Routing (SR) path
      or tunnel is described in <xref
      target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>. <xref
      target="RFC8400"/> specifies the fast protection of egress node(s) of an
      MPLS TE LSP tunnel including P2P TE LSP tunnel and P2MP TE LSP tunnel in
      details. However, these documents do not discuss the fast protection of
      the egress node of a Segment Routing for IPv6 (SRv6) path or tunnel.</t>

      <t>This document fills that void and presents protocol extensions for
      the fast protection of the egress node of an SRv6 path or tunnel. Egress
      node and egress, fast protection and protection as well as SRv6 path and
      SRv6 tunnel will be used exchangeably below.</t>

      <t>There are a number of topics related to the egress protection, which
      include the detection of egress node failure, the relation between
      egress protection and global repair, and so on. These are discussed in
      details in <xref target="RFC8679"/>.</t>
    </section>

    <!-- Introduction -->

    <section title="Terminologies">
      <t>The following terminologies are used in this document. <list
          style="hanging">
          <t hangText="SR:">Segment Routing</t>

          <t hangText="SRv6:">SR for IPv6</t>

          <t hangText="SRH:">Segment Routing Header</t>

          <t hangText="SID:">Segment Identifier</t>

          <t hangText="LSA:">Link State Advertisement in OSPF</t>

          <t hangText="LSP:">Label Switched Path in MPLS or Link State
          Protocol PDU in IS-IS</t>

          <t hangText="PDU:">Protocol Data Unit</t>

          <t hangText="LS:">Link Sate, which is LSA in OSPF or LSP in
          IS-IS</t>

          <t hangText="TE:">Traffic Engineering</t>

          <t hangText="SA:">Source Address</t>

          <t hangText="DA:">Destination Address</t>

          <t hangText="P2MP:">Point-to-MultiPoint</t>

          <t hangText="P2P:">Point-to-Point</t>

          <t hangText="CE:">Customer Edge</t>

          <t hangText="PE:">Provider Edge</t>

          <t hangText="LFA:">Loop-Free Alternate</t>

          <t hangText="TI-LFA:">Topology Independent LFA</t>

          <t hangText="BFD:">Bidirectional Forwarding Detection</t>

          <t hangText="VPN:">Virtual Private Network</t>

          <t hangText="L3VPN:">Layer 3 VPN</t>

          <t hangText="VRF:">Virtual Routing and Forwarding</t>

          <t hangText="FIB:">Forwarding Information Base</t>

          <t hangText="PLR:">Point of Local Repair</t>

          <t hangText="BGP:">Border Gateway Protocol</t>

          <t hangText="IGP:">Interior Gateway Protocol</t>

          <t hangText="OSPF:">Open Shortest Path First</t>

          <t hangText="IS-IS:">Intermediate System to Intermediate System</t>
        </list></t>
    </section>

    <!-- Terminologies -->

    <section title="SR Path Egress Protection">
      <t>This section describes the mechanism of SR path egress protection and
      illustrates it through an example.</t>

      <section title="Mechanism">
        <t><xref target="SR-Protect-Egress-A"/> is used to explain the
        mechanism of SR path egress node protection. <figure
            anchor="SR-Protect-Egress-A"
            title="PEB Protects Egress PEA of SR Path">
            <artwork><![CDATA[                                    
            *******  *******   SIDa
        [PE1]-----[P1]-----[PEA]---[CE2]    PEA Egress
        / |        |&        | \   /        PEB Backup Egress
       /  |        |&        |  \ /         CEx Customer Edge
  [CE1]   |        |&        |   X          Px  Non-Provider Edge
       \  |        |&        |  / \         *** SR Path
        \ |        |& &&&&&  | /   \        &&& Backup Path
        [PE2]-----[P2]-----[PEB]---[CE3]                                                                       
                        Mirror SID]]></artwork>
          </figure> Where node PEA is the egress of the SR path from PE1 to
        PEA, and has SIDa which is the active segment in the packet from the
        SR path at PEA. Node PEB is the backup egress (or say protector) to
        provide the protection for egress (or say primary egress) PEA. Node P1
        is the direct previous/upstream hop of egress PEA and 
        acts as PLR 
        (refer to <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/>)
        to support the protection for PEA.</t>

        <t>When PEB is selected as a backup egress to protect the egress PEA,
        a Mirror SID (refer to Section 5.1 of <xref target="RFC8402"/>) is
        configured on PEB to protect PEA. PEB advertises this information
        through IGP, which includes the Mirror SID and the egress PEA. The
        information is represented by &lt;PEB, PEA, Mirror SID&gt;, which
        indicates that PEB protects PEA with Mirror SID.</t>

        <t>After PEA receives the information &lt;PEB, PEA, Mirror SID&gt;, it
        may send the forwarding behavior of the SIDa at PEA to PEB with the
        Mirror SID using some protocols such as BGP if PEB can not obtain this
        behavior from other approaches and PEB wants to protect SIDa of PEA.
        How to send the forwarding behavior of the SIDa to PEB is out scope of
        this document.</t>

        <t>When PEB gets the forwarding behavior of the SIDa of PEA from PEA
        or other means, it adds a forwarding entry for the SIDa according to
        the behavior into the forwarding table for node PEA. This table is
        identified by the Mirror SID, which indicates node PEA's context.
        Using the forwarding entry for SIDa in this table, a packet with SIDa
        will be transmitted by PEB to the same destination as it is
        transmitted by PEA. For example, assume that the packet with SIDa is
        transmitted by PEA to CE2 through the forwarding behavior of the SIDa
        in PEA. The packet will be transmitted by PEB to the same CE2 through
        looking up the table identified by the Mirror SID.</t>

        <t>After P1 as PLR receives the information &lt;PEB, PEA, Mirror
        SID&gt; and knows that PEB wants to protect SIDa of PEA, it computes
        an LFA for PEA assuming that PEA and PEB have a same anycast address.
        A Repair List RL (or say backup path) is obtained based on the LFA.
        It is one of the following: <list style="hanging">
            <t hangText="o">RL = &lt;Mirror SID&gt; if the LFA is the next 
               hop node to PEB along the shortest path to PEB; or</t>

            <t hangText="o">RL = &lt;S1, ..., Sn, Mirror SID&gt; if the LFA is
            a TI-LFA, where &lt;S1, ..., Sn&gt; is the TI-LFA Repair
            List to PEB computed by P1.</t>
          </list></t>

        <t>When PEA fails, P1 as PLR sends the packet with SIDa carried by the
        SR path to PEB, but encapsulates the packet before sending it by
        executing H.Encaps with the Repair List RL and a Source Address T.</t>

<t>P1 as PLR needs to
   retain the route to PEA for a period of time 
   after its IGP converges on the failure of PEA.  Thus the backup path
   for PEA will be used when the other nodes (such as PE1) still send
   the packet to PEA via P1 since their IGPs do not converge on the
   failure.
</t>

        <t>Suppose that the packet received by P1 is represented by Pkt = (S,
        SIDa)Pkt0, where SA = S and DA = SIDa, and Pkt0 is the rest of the
        packet.</t>

        <t>The execution of H.Encaps pushes an IPv6 header to Pkt and sets
        some fields in the outer and inner IPv6 header to produce an
        encapsulated packet Pkt'. Pkt' will be one of the following: <list
            style="hanging">
            <t hangText="o">Pkt' = (T, Mirror SID) (S, SIDa)Pkt0 if RL =
            &lt;Mirror SID&gt;; or</t>

            <t hangText="o">Pkt' = (T, S1)(Mirror SID, Sn, ..., S1; SL=n) (S,
            SIDa)Pkt0 if RL = &lt;S1, ..., Sn, Mirror SID&gt;.</t>
          </list></t>

        <t>When PEB receives the re-routed packet, which is (T, Mirror SID)
        (S, SIDa)Pkt0, it decapsulates the packet and forwards the
        decapsulated packet using the FIB table Tm identified by the Mirror SID
        as a variant of End.DT6 SID. The Mirror SID
        is called End.M.</t>

        <t>It obtains the Mirror SID in the outer IPv6 header of the packet,
        removes this outer IPv6 header with all its extension headers, and
        then processes the inner IPv6 packet (i.e., (S, SIDa)Pkt0, the packet
        without the outer IPv6 header). PEB finds the FIB table Tm for node PEA
        using the Mirror SID as the context ID, and submits the packet to this
        FIB table lookup and transmission to the same destination as PEA
        does.</t>

        <t>The behavior of Mirror SID (End.M for short) is a variant of
           the End.DT6 behavior (refer to Section 4.6 of 
           <xref target="RFC8986"/>). 
           The End.M SID MUST be the last segment in an SR path, 
           and a SID instance is associated with an IPv6 FIB table Tm.</t>

       <t>When processing the Upper-Layer header of a packet matching 
          a FIB entry locally instantiated as an End.M SID,
          N does the following:</t>
<t>
<figure>
            <artwork><![CDATA[
    S01. If (Upper-Layer header type == 41(IPv6) ) {
    S02.    Remove the outer IPv6 header with all its extension headers
    S03.    Set the packet's associated FIB table to Tm
    S04.    Submit the packet to the egress IPv6 FIB lookup for
               transmission to the new destination
    S05. } Else {
    S06.    Process as per Section 4.1.1 of RFC8986
    S07. }]]></artwork>
</figure>
</t>
      </section>

      <!-- Mechanism -->

      <section title="Example">
        <t><xref target="SR-Protect-Egress-PE3"/> shows an example of
        protecting egress PE3 of a SR path, which is from ingress PE1 to
        egress PE3. <figure anchor="SR-Protect-Egress-PE3"
            title="PE4 Protects Egress PE3 of SR Path">
            <artwork><![CDATA[ 
                                Locator: A3:1::/64
              *******  *******  VPN SID: A3:1::B100
          [PE1]-----[P1]-----[PE3]---[CE2]      PE3 Egress
          / |        |&        | \   /          PE4 Backup Egress
         /  |        |&        |  \ /           CEx Customer Edge
    [CE1]   |        |&        |   X            Px  Non-Provider Edge
         \  |        |&        |  / \           *** SR Path
          \ |        |& &&&&&  | /   \          &&& Backup Path
          [PE2]-----[P2]-----[PE4]---[CE3]
                                Locator: A4:1::/64 
                                VPN SID: A4:1::B100
                             Mirror SID: A4:1::3, protect A3:1::/64]]></artwork>
          </figure> Where node P1's pre-computed backup path for PE3 is from
        P1 to PE4 via P2. In normal operations, after receiving a packet with
        destination PE3, P1 forwards the packet to PE3 according to its FIB.
        When PE3 receives the packet, it sends the packet to CE2.</t>

        <t>When PE3 fails, P1 as PLR detects the failure through using a
        failure detection mechanism such as BFD and forwards the packet to PE4
        via the backup path. When PE4 receives the packet, it sends the packet
        to the same CE2.</t>

        <t>When P1's IGP converges on the failure of PE3, P1 as PLR needs to
        retain the route to PE3 for a period of time. 
        Thus the backup path for PE3 will be used when the other nodes 
        (such as PE1) still send the packet to PE3 via P1 since their IGPs
        do not converge on the failure.</t>

        <t>In <xref target="SR-Protect-Egress-PE3"/>, Both CE2 and CE3 are
        dual home to PE3 and PE4. PE3 has a locator A3:1::/64 and a VPN SID
        A3:1::B100. PE4 has a locator A4:1::/64 and VPN SID A4:1::B100. A
        Mirror SID A4:1::3 is configured on PE4 for protecting PE3 with
        locator A3:1::/64. </t>

        <t>After the configuration, PE4 advertises this information through an
        IGP LS (i.e., LSA in OSPF or LSP in IS-IS), which includes PE3's
        locator and Mirror SID A4:1::3. Every node in the SR domain will
        receive this IGP LS, which indicates that PE4 wants to protect PE3 
        (indicated by PE3's locator) with Mirror SID A4:1::3.</t>

        <t>When PE4 (e.g., BGP on PE4) receives a prefix whose VPN SID belongs
        to PE3 that is protected by PE4 through Mirror SID A4:1::3, it finds
        PE4's VPN SID corresponding to PE3's VPN SID. For example, local PE4
        has Prefix 1.1.1.1 with VPN SID A4:1::B100, when PE4 receives prefix
        1.1.1.1 with remote PE3's VPN SID A3:1::B100, it knows that they are
        for the same VPN.</t>

        <t>The forwarding behaviors for these two VPN SIDs are the same from
        function's point of view. If the behavior for PE3's VPN SID in PE3
        forwards the packet with it to CE2, then the behavior for PE4's VPN
        SID in PE4 forwards the packet to the same CE2; and vice versa. PE4
        creates a forwarding entry for PE3's VPN SID A3:1::B100 in the FIB
        table identified by Mirror SID A4:1::3 according to the forwarding
        behavior for PE4's VPN SID A4:1::B100.</t>

        <!--
    <t>(Note: alternatively, the entry created may map PE3's VPN SID A3:1::B100 
    to PE4's VPN SID A4:1::B100. PE4 uses its VPN SID to forward the packet
    in its forwarding table. This is a local decision.)</t> 
-->

        <t>Node P1's pre-computed backup path for destination PE3 is
        from P1 to PE4 having mirror SID A4:1::3. When P1 receives a packet
        destined to PE3's VPN SID A3:1::B100, in normal operations, it
        forwards the packet with source A1:1:: and destination PE3's VPN SID
        A3:1::B100 according to the FIB using the destination PE3's VPN SID
        A3:1::B100.</t>

        <t>When PE3 fails, P1 as PLR sends the packet to PE4 via the backup
        path pre-computed. P1 encapsulates the packet using H.Encaps before
        sending it to PE4.</t>

        <t>Suppose that the packet received by P1 is represented by Pkt = (SA
        = A1:1::, DA = A3:1::B100)Pkt0, where DA = A3:1::B100 is PE3's VPN
        SID, and Pkt0 is the rest of the packet. The encapsulated packet Pkt'
        will be one of the following: <list style="hanging">
            <t hangText="o">Pkt' = (T, Mirror SID A4:1::3) (A1:1::,
            A3:1::B100)Pkt0 if the LFA is the next hop node to PE4 along the
      shortest path to PE4; or (otherwise)</t>

            <t hangText="o">Pkt' = (T, S1)(Mirror SID A4:1::3, Sn, ..., S1;
            SL=n) (A1:1::, A3:1::B100)Pkt0.</t>
          </list> where T is a Source Address, &lt;S1, ..., Sn&gt; is the
        TI-LFA Repair List to PE4 computed by P1.</t>

        <t>When PE4 receives the re-routed packet, it decapsulates the packet
        and forwards the decapsulated packet by executing the behavior of
        End.M for the Mirror SID
        that is associated with the IPv6 FIB table for PE3. The packet
        received by PE4 is (T, Mirror SID A4:1::3) (A1:1::, PE3's VPN SID
        A3:1::B100)Pkt0.</t>

        <t>PE4 obtains Mirror SID A4:1::3 in the outer IPv6 header of the
        packet, removes this outer IPv6 header, and then processes the inner
        IPv6 packet (A1:1::, A3:1::B100)Pkt0. It finds the FIB table for PE3
        using Mirror SID A4:1::3 as the context ID, gets the forwarding entry
        for PE3's VPN SID A3:1::B100 from the table, and forwards the packet
        to CE2 using the entry.</t>
      </section>

      <!-- Example -->
    </section>

    <!-- SR Path Egress Protection -->

    <section title="Extensions to IGP for Egress Protection">
      <t>This section describes extensions to IS-IS and OSPF for advertising
      the information about SRv6 path egress protection.</t>

      <section title="Extensions to IS-IS">
        <t>A new sub-TLV, called IS-IS SRv6 Mirror SID sub-TLV, is defined. It
        is used in the SRv6 Locator TLV defined in <xref
        target="RFC9352"/> to advertise SRv6 Mirror
        SID and the locators of the nodes to be protected. The SRv6 Mirror SID
        inherit the topology/algorithm from the parent locator. The format of
        the sub-TLV is illustrated below.<figure
            anchor="isis-srv6-mirror-sid-sub-tlv"
            title="IS-IS SRv6 Mirror SID sub-TLV">
            <artwork><![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 (TBD1)   |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Flags     |    SRv6 Endpoint Function     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SID (16 octets)                       |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         sub-sub-TLVs                          |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t><list style="hanging">
            <t hangText="Type:">TBD1 (suggested value 8) is to be assigned by
            IANA.</t>

            <t hangText="Length:">variable.</t>

            <t hangText="Flags:">1 octet. No flags are currently defined. </t>

            <t hangText="SRv6 Endpoint Function:">2 octets. It contains the endpoint
            function 74 for Mirror SID.</t>

            <t hangText="SID:">16 octets. This field contains the SRv6 Mirror
            SID to be advertised.</t>
          </list></t>

<!--
        <t>Two sub-sub-TLVs are defined. One is the protected locators sub-sub-TLV, and
        the other is the protected SIDs sub-sub-TLV.</t>
-->
        <t>A protected locators sub-sub-TLV is defined and used to carry 
        the Locators of the egress nodes to be
        protected by the SRv6 mirror SID. It has the following format.<figure
            anchor="isis-protected-node-sub-tlv"
            title="IS-IS Protected Locators sub-sub-TLV">
            <artwork><![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 (TBD2)  |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  | Locator (variable)            ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  | Locator (variable)            ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t><list style="hanging">
            <t hangText="Type:">TBD2 (suggested value 1) is to be assigned by
            IANA.</t>

            <t hangText="Length:">variable. </t>

            <t hangText="Locator-Size:">1 octet. Number of bits (1 - 128) in
            the Locator field.</t>

            <t hangText="Locator:">1-16 octets. This field encodes an SRv6
            Locator of an egress node to be protected by the SRv6 mirror SID. 
            The Locator is
            encoded in the minimal number of octets for the given number of
            bits.</t>
          </list></t>

<!--
        <t>A protected SIDs sub-sub-TLV is used to carry the SIDs to be protected
        by the SRv6 Mirror SID. It has the following format. <figure
            anchor="isis-protected-sids-sub-tlv"
            title="IS-IS Protected SIDs sub-sub-TLV">
            <artwork><![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 (TBD3)  |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   SID-Size    |         SID (variable)                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   SID-Size    |         SID (variable)                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure> <list style="hanging">
            <t hangText="Type:">TBD3 (suggested value 2) is to be assigned by
            IANA.</t>

            <t hangText="Length:">variable.</t>

            <t hangText="SID-Size:">1 octet. Number of bits in the SID field.
            It is from 1 to 128. When it is less than 128, the SID field is a
            locator. When it is 128, the SID field is an SRv6 SID.</t>

            <t hangText="SID:">1-16 octets. This field encodes an SRv6 SID 
            to be protected. The SID is encoded in the minimal
            number of octets for the given number of bits. Trailing bits MUST
            be set to zero and ignored when received.</t>
          </list></t>
-->
        <t>When node B advertises that B wants to protect node A
        with a Mirror SID through an LSP, the LSP contains an IS-IS SRv6
        Mirror SID sub-TLV, which includes the Mirror SID and node A's
        locator in an IS-IS Protected locators sub-sub-TLV. </t>
<!--
        <t>Note: the IS-IS extensions for SR MPLS is described in <xref
        target="RFC8667"/>. It says that the SID/Label Binding TLV may also be
        used to advertise a Mirror SID. For B to protect egress A of SR MPLS
        path, B may also use this TLV to advertise the node A's ID and a
        specific set of SIDs of A to be protected. An IS-IS SR MPLS Mirror SID
        sub-TLV may be obtained from an IS-IS SRv6 Mirror SID sub-TLV by
        replacing each SID field in the latter with an SID/Label sub-TLV. B
        may advertise a SID/Label Binding TLV including this IS-IS SR MPLS
        Mirror SID sub-TLV.</t>

        <t>Alternatively, an IS-IS SR MPLS Mirror Supplement sub-TLV is
        defined from an IS-IS SRv6 Mirror SID sub-TLV by removing the SID
        field in the top level and replacing each other SID field with an
        SID/Label sub-TLV. That is that an IS-IS SR MPLS Mirror Supplement
        sub-TLV just contains a Protected Node sub-TLV and a Protected SIDs
        sub-TLV, which includes SID/Label sub-TLVs. When the SID/Label Binding
        TLV contains an SID/Label sub-TLV for the Mirror SID, it includes an
        IS-IS SR MPLS Mirror Supplement sub-TLV.</t>
-->
      </section>

      <!-- Extensions to IS-IS -->

      <section title="Extensions to OSPF">
        <t>Similarly, a new sub-TLV, called OSPF Mirror SID sub-TLV, is
        defined. It is used to advertise SRv6 Mirror SID and the locators of
        the nodes to be protected. Its format is illustrated below.<figure
            anchor="ospf-srv6-mirror-sid-sub-tlv"
            title="OSPF SRv6 Mirror SID sub-TLV">
            <artwork><![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 (TBD4)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Flags     |    Reserved   |    SRv6 Endpoint Function     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         SID (16 octets)                       |
 :                                                               :
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            sub-TLVs                           |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t><list style="hanging">
            <t hangText="Type:">TBD4 (suggested value 8) is to be assigned by
            IANA.</t>

            <t hangText="Length:">variable.</t>

            <t hangText="Flags:">1 octet. No flags are currently defined.</t>
            <t hangText="Reserved:">1 octet. It MUST be set to zero for transmission 
               and ignored on reception.</t>

            <t hangText="SRv6 Endpoint Function:">2 octets. It contains the endpoint
            function 74 for End.M SID.</t>

            <t hangText="SID:">16 octets. This field contains the SRv6 Mirror
            SID to be advertised.</t>
          </list></t>
<!--
        <t>Two sub-TLVs are defined. One is the protected locators sub-TLV, and
        the other is the protected SIDs sub-TLV.</t>
-->
        <t>A protected locators sub-TLV is defined and used to carry the locators of the
        nodes to be protected by the SRv6 Mirror SID. It has the following
        format.<figure anchor="ospf-protected-node-sub-tlv"
            title="OSPF Protected Locators sub-TLV">
            <artwork><![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 (TBD5)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  |  Locator (variable)           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Locator-Size  |  Locator (variable)           ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t><list style="hanging">
            <t hangText="Type:">TBD5 (suggested value 1) is to be assigned by
            IANA.</t>

            <t hangText="Length:">variable.</t>

            <t hangText="Locator-Size:">1 octet. Number of bits (1 - 128) in
            the Locator field.</t>

            <t hangText="Locator:">1-16 octets. This field encodes an SRv6
            Locator of an egress node to be protected by the SRv6 mirror SID. 
            The Locator is
            encoded in the minimal number of octets for the given number of
            bits.</t>
          </list></t>

<!--
        <t>A protected SIDs sub-TLV is used to carry the SIDs to be protected
        by the SRv6 Mirror SID. It has the following format. <figure
            anchor="ospf-protected-sids-sub-tlv"
            title="OSPF Protected SIDs sub-TLV">
            <artwork><![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 (TBD6)           |             Length            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   SID-Size    |         SID (variable)                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |   SID-Size    |         SID (variable)                        ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
          </figure></t>

        <t><list style="hanging">
            <t hangText="Type:">TBD6 (suggested value 2) is to be assigned by
            IANA.</t>

            <t hangText="Length:">variable.</t>

            <t hangText="SID-Size:">1 octet. Number of bits in the SID field.
            It is from 1 to 128. When it is less than 128, the SID field is a
            locator. When it is 128, the SID field is an SRv6 SID.</t>

            <t hangText="SID:">1-16 octets. This field encodes an SRv6 SID
            to be protected. The SID is encoded in the minimal
            number of octets for the given number of bits. Trailing bits MUST
            be set to zero and ignored when received.</t>
          </list></t>
-->
      </section>

      <!-- Extensions to OSPF -->
    </section>

    <!-- Extensions to IGP -->

    <section anchor="Security" title="Security Considerations">
      <t>The security about the egress protection is described in in details
      in <xref target="RFC8679"/>. The extensions to OSPF and IS-IS described
      in this document for SRv6 path egress protection should not cause extra
      security issues.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section anchor="SRv6-End" title="SRv6 Endpoint Behaviors">
        <t>Under sub-registry "SRv6 Endpoint Behaviors" <xref
        target="RFC8986"/>, IANA has assigned the following
        for End.M Endpoint Behavior: <figure>
            <artwork><![CDATA[
  +==============+========+=====================+===============+
  | Value        | Hex    | Endpoint behavior   | Reference     |
  +==============+========+=====================+===============+
  |   74         | 0x004A | End.M (Mirror SID)  | This document |
  +--------------+--------+---------------------+---------------+
  ]]></artwork>
          </figure></t>
      </section>

      <section anchor="IS-IS" title="IS-IS">
        <t>Under 
"IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability registry", 
IANA is requested to add
        the following new Sub-TLV: <figure>
            <artwork><![CDATA[
  +==============+=========================+===============+
  |     Type     | Description             | Reference     |
  +==============+=========================+===============+
  |     8        | SRv6 Mirror SID         | This document |
  +--------------+-------------------------+---------------+ 
  ]]></artwork>
          </figure></t>

        <t>IANA is requested to create and maintain a new registry for
        sub-sub-TLVs of the SRv6 Mirror SID Sub-TLV. The suggested registry
        name is <list style="hanging">
            <t hangText=" o">Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV</t>
          </list> Initial values for the registry are given below. The future
        assignments are to be made through IETF Review <xref
        target="RFC5226"/>. <figure>
            <artwork><![CDATA[ 
  Value    Sub-Sub-TLV Name                 Definition
  -----   -----------------------          -------------
  0       Reserved
  1       Protected Locators Sub-Sub-TLV   This Document
  2-255   Unassigned
 ]]></artwork>
          </figure></t>
      </section>

      <!-- IS-IS -->

      <section anchor="OSPFv3" title="OSPFv3">
        <t>Under registry "OSPFv3 Locator LSA Sub-TLVs" <xref
        target="I-D.ietf-lsr-ospfv3-srv6-extensions"/>, IANA is requested to
        assign the following new Sub-TLVs: <figure>
            <artwork><![CDATA[
  +==============+============================+===============+
  | Sub-TLV Type | Sub-TLV Name               | Reference     |
  +==============+============================+===============+
  |     8        | SRv6 Mirror SID Sub-TLV    | This document |
  +--------------+----------------------------+---------------+
  |     11       | Protected Locators Sub-TLV | This document |
  +--------------+----------------------------+---------------+ ]]></artwork>
          </figure></t>
      </section>

      <!-- OSPFv3 -->
    </section>


  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
<!-- <?rfc include="reference.RFC.7356"?> -->
<!-- <?rfc include="reference.RFC.7490"?> -->

      <?rfc include="reference.RFC.8400"?>

      <?rfc include="reference.RFC.8402"?>

<!--  <?rfc include="reference.RFC.8665"?> -->

      <?rfc include="reference.RFC.8667"?>

      <?rfc include="reference.RFC.8679"?>
      <?rfc include="reference.RFC.8986"?>

      <?rfc include="reference.I-D.ietf-lsr-ospfv3-srv6-extensions"?>

<!--  <?rfc include="reference.I-D.ietf-lsr-isis-srv6-extensions"?> -->
      <?rfc include="reference.RFC.9352"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>

<!--  <?rfc include="reference.I-D.ietf-spring-segment-routing-policy"?> -->

      <?rfc include="reference.RFC.5226"?>

<!--  <?rfc include="reference.RFC.5462"?> -->
    </references>

    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
       <t>The authors would like to thank Acee Lindem, Peter Psenak, Yimin Shen,
       Jie Dong, Zhenqiang Li, 
       Alexander Vainshtein, Greg Mirsky, Bruno Decraene, Jeff Tantsura,
       Chris Bowers, Ketan Talaulikar and Bob Halley for their comments to this work.</t>
    </section>

    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors' Addresses</name>
      <figure>
        <artwork>Huanan Chen
China Telecom
109, West Zhongshan Road, Tianhe District
Guangzhou
510000
China
Email: chenhn8.gd@chinatelecom.cn

Peng Wu
Huawei
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: baggio.wupeng@huawei.com

Lei Liu
Fujitsu
United States of America
Email: liulei.kddi@gmail.com

Xufeng Liu
Alef Edge
United States of America
Email: xufeng.liu.ietf@gmail.com</artwork>
      </figure>
    </section>

  </back>
</rfc>
