<?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-chen-bier-te-egress-protect-07"
     ipr="trust200902">
  <front>
    <title abbrev="BIER-TE Egress Protect">BIER-TE Egress Protection</title>

     <author initials="H" surname="Chen" fullname="Huaimo Chen">
      <organization>Futurewei</organization>
      <address>
        <postal>
          <street></street>
          <city>Boston, MA</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>hchen.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Mike McBride" initials="M" surname="McBride">
      <organization>Futurewei</organization>
      <address>
        <email>michael.mcbride@futurewei.com</email>
      </address>
    </author>

     <author initials="A" fullname="Aijun Wang" 
            surname="Wang">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street>Beiqijia Town, Changping District</street>
          <city>Beijing</city>
          <region> </region>
          <code>102209</code>
          <country>China</country>
        </postal>
        <email>wangaj3@chinatelecom.cn</email>
      </address>
    </author>

    <author fullname="Gyan S. Mishra" initials="G" surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <postal>
          <street>13101 Columbia Pike</street>
          <city>Silver Spring</city>
          <code>MD 20904</code>
          <country>USA</country>
        </postal>
        <phone> 301 502-1347</phone>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>

     <author initials="Y" fullname="Yisong Liu" 
            surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <email>liuyisong@chinamobile.com</email>
      </address>
    </author>



   <author initials="Y" fullname="Yanhe Fan" 
            surname="Fan">
      <organization>Casa Systems</organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>yfan@casa-systems.com</email>
      </address>
    </author>

   <author initials="L" fullname="Lei Liu" 
            surname="Liu">
      <organization>Fujitsu</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>liulei.kddi@gmail.com</email>
      </address>
    </author>

  <author initials="X" fullname="Xufeng Liu" 
            surname="Liu">
      <organization>Alef Edge</organization>
      <address>
        <postal>
          <street> </street>
          <city> </city>
          <region> </region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2024"/>

    <abstract>
      <t>This document describes a mechanism for fast  
         protection against the failure of an egress node of 
         an explicit point to multipoint (P2MP) multicast path/tree in 
         a "Bit Index Explicit Replication" (BIER) Traffic Engineering (TE) 
         domain.

         It does not have any per-flow state in the core of the domain.
         For a multicast packet to the egress node,
         when the egress node fails, its upstream hop as a PLR sends 
         the packet to the egress' backup node  
         once the PLR detects the failure.</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"/> <xref target="RFC8174"/> 
      when, and only when, they appear in all capitals, as shown here.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
     <t><xref target="RFC9262"/> introduces
        Bit Index Explicit Replication (BIER) Traffic/Tree Engineering
        (BIER-TE).
        It is an architecture for per-packet stateless explicit 
        point to multipoint (P2MP) multicast path/tree and
        based on the BIER architecture defined in <xref target="RFC8279"/>.
        A multicast packet is replicated and forwarded along
        the P2MP path/tree encoded in the packet.   
        It does not require intermediate nodes to maintain any 
        per-path/tree state.</t>

      <t>This document describes a mechanism for fast  
         protection against the failure of an egress node of 
         an explicit P2MP multicast path/tree in 
         a BIER-TE domain.
         It is called BIER-TE Egress Protection.

         For a multicast packet to the egress node,
         when the egress node fails, its upstream hop as a PLR sends 
         the packet to the egress' backup node (called backup egress node) 
         once the PLR detects the failure.</t>

      <t>This BIER-TE Egress Protection does not require intermediate 
         nodes to maintain
         any per-path state for fast protection against the failure of 
         an egress node of the path.</t>

    <section title="Terminology">
      <t>
      <list style="hanging" hangIndent="6">
       <t hangText="BIER:">Bit Index Explicit Replication.</t>
       <t hangText="BIER-TE:">BIER Traffic/Tree Engineering.</t>
       <t hangText="BFR:">Bit-Forwarding Router.</t>
       <t hangText="BFIR:">Bit-Forwarding Ingress Router.</t>
       <t hangText="BFER:">Bit-Forwarding Egress Router.</t>
       <t hangText="BFR-id:">BFR Identifier. 
          It is a number in the range [1,65535].</t>
       <t hangText="BFR-NBR:">BFR Neighbor.</t>
       <t hangText="F-BM:">Forwarding Bit Mask.</t>
       <t hangText="BFR-prefix:">An IP address (either IPv4 or IPv6) of a BFR.</t>
       <t hangText="BIRT:">Bit Index Routing Table. 
          It is a table that maps from the BFR-id (in a particular sub-domain)
          of a BFER to the BFR-prefix of that BFER, and to the BFR-NBR 
          on the path to that BFER.</t>
       <t hangText="BIFT:">Bit Index Forwarding Table.</t>

       <t hangText="FRR:">Fast Re-Route.</t>
       <t hangText="PLR:">Point of Local Repair.</t>

       <t hangText="IGP:">Interior Gateway Protocol.</t>
       <t hangText="LSDB:">Link State DataBase.</t>
       <t hangText="SPF:">Shortest Path First.</t>
       <t hangText="SPT:">Shortest Path Tree.</t>
       <t hangText="OSPF:">Open Shortest Path First.</t>
       <t hangText="IS-IS:">Intermediate System to Intermediate System.</t>
       <t hangText="LSA:">Link State Advertisement in OSPF.</t>
       <t hangText="LSP:">Link State Protocol Data Unit (PDU) in IS-IS.</t>

      </list></t>
    </section> <!-- Terminology -->

    </section> <!-- Introduction -->


    <section title="Overview of BIER-TE Egress Protection"> 
      <t>For fast protecting an egress node of a BIER-TE domain, 
         a backup egress node is configured on the egress node.
         After the configuration, the egress node distributes 
         the information about the backup egress to its direct neighbors.</t>

      <t>For clearly distinguishing between an egress node and a backup 
         egress node, an egress node is called a primary egress node
         sometimes. </t>
 
      <t>For a multicast packet to a primary egress node of the domain,
         when the primary egress node fails, its upstream hop as a 
         point of local repair (PLR) sends the packet
         to the backup egress node configured to protect the primary  
         egress node once the PLR detects the failure.
         The upstream hop of the primary egress node is its direct 
         neighbor.</t>

       <t>A Bit-Forwarding Router (BFR) in a BIER-TE sub-domain has 
         a BIER-TE Bit Index Forwarding Tables (BIFT)
         <xref target="RFC9262"/>.
         A BIER-TE BIFT on a BFR comprises a forwarding entry for 
         a BitPosition (BP) assigned to each of the adjacencies of the BFR. 
         If the BP represents a forward connected adjacency, 
         the forwarding entry for the BP forwards the multicast packet 
         with the BP to the directly connected BFR neighbor of the adjacency.
         If the BP represents a BFER (i.e., egress node) 
         or say a local decap adjacency,
         the forwarding entry for the BP decapsulates the multicast packet
         with the BP and passes a copy of the payload of the packet
         to the packet's NextProto within the BFR. </t>
    
      <t>The BIER-TE BIFT on a BFR is extended to support protection
         against the failure of an egress node. 
         For each forwarding entry of the BIER-TE BIFT on the BFR, 
         if it is for the BP representing a forward connected adjacency
         and its BFR-NBR is a BFER (i.e., primary egress node),
         the forwarding entry is extended to include a new 
         forwarding entry, which is called backup forwarding entry or
         backup entry for short.
         This backup entry forwards the multicast packet with the BP
         to the backup egress node, which is configured to protect
         the primary egress node.</t>

       <t>Once the BFR as a PLR detects the failure of its BFR-NBR X
          that is a primary egress node of the domain,
          for a multicast packet with the BP for the primary egress node, 
          the PLR uses the backup forwarding entry in 
          the extended BIER-TE BIFT to send the packet to the  
          backup egress node configured to protect the primary  
          egress node.</t> 
    </section> <!-- Overview of BIER-TE Egress Protection -->


    <section title="Protocol Extensions">
      <t>This section defines extensions to OSPF and IS-IS for advertising 
         the backup information (including the information about the backup 
         egress node for protecting a primary egress node).</t>

     <section title="Extensions to OSPF">
      <t>When a node P (as a primary egress node) has a backup egress
         node configured to protect against its failure,
         node P advertises the information about the backup egress 
         node to its neighbors  
         in its router information opaque LSA of LS type 9 or 10. 
         The information is included in a
         backup egress BP TLV. The format of the TLV is shown in
         <xref target="ospf-backup-egress-tlv"/>.

<figure anchor="ospf-backup-egress-tlv" 
        title="OSPF Backup Egress BP 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            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Reserved              |   BP of backup egress node    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Sub-TLVs (Optional)                     |
 :                                                               :
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
         Type: 2 octets, its value (TBD1) is to be assigned by IANA.</t>

      <t>Length: 2 octets, its value is 4 plus the length of the 
         Sub-TLVs included. If no Sub-TLV is included, its value is 4.</t>
      <t>Reserved: 2 octets, it MUST be set to zero when sending 
         and be ignored while receiving.</t>
      <t>BP of backup egress node: 2 octets, its value is the local decap
         BitPosition of the backup egress node, 
         which is configured to protect against 
         the failure of the primary egress node.</t>
      <t>Sub-TLVs (Optional): No Sub-TLV is defined now.</t>

      <t>After each of the neighbors receives the backup egress BP TLV
         from node P, it knows that node P as a primary egress node
         will be protected by the backup egress node in the TLV.
         Once detecting the failure of node P, it sends the packet
         with the BP for node P towards the backup egress node.</t>

     </section> <!-- Extensions to OSPF -->


     <section title="Extensions to IS-IS">
      <t>For supporting fast protection against the failure of 
         a primary egress node in a BIER-TE domain, 
         a new IS-IS TLV, called IS-IS backup egress BP TLV, is defined.
         It contains the local decap BitPosition of the backup
         egress node configured to protect the primary egress node.</t>

      <t>When a node P (as a primary egress node) has a backup egress
         node configured to protect against its failure,
         node P advertises the information about the backup egress 
         node to its neighbors using a IS-IS backup egress BP TLV.</t> 
 
      <t>This TLV may be advertised in IS-IS Hello (IIH) PDUs, 
         LSPs, or in Circuit Scoped Link State PDUs (CS-LSP) 
         <xref target="RFC7356"/>.
         The format of the TLV is shown in
         <xref target="isis-backup-egress-tlv"/>. 

<figure anchor="isis-backup-egress-tlv" 
                    title="IS-IS Backup Egress BP TLV">
          <artwork align="center"><![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    |   BP of backup egress node    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~                      Sub-TLVs (Optional)                      ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
         Type: 1 octet, its value (TBD2) is to be assigned by IANA.</t>

      <t>Length: 1 octet, its value is 2 plus the length of the 
         Sub-TLVs included. If no Sub-TLV is included, its value is 2.</t>
      <t>BP of backup egress node: 2 octets, its value is the local decap
         BitPosition of the backup egress node configured to protect against 
         the failure of the primary egress node.</t>
      <t>Sub-TLVs (Optional): No Sub-TLV is defined now.</t>

     </section> <!-- Extensions to IS-IS -->

   </section> <!-- Protocol Extensions -->


   <section title="BIER-TE Extensions"> 
     <t>This section describes extensions to a BIER-TE BIFT of a BFR
        for supporting fast protection against the failure of a primary
        egress node and enhancements on a forwarding procedure to use
        the extended BIER-TE BIFT for egress protection.</t>

    <section title="Extensions to BIER-TE BIFT for Egress Protection">    
      <t>If a BFR is a neighbor of an egress node 
         in a BIER-TE sub-domain,  
         it has an extended BIER-TE BIFT to support
         protection against the failure of its neighbor egress node.

         The forwarding entry with the egress node (say X) as its BFR-NBR 
         in the BIFT comprises a backup entry.
         The backup entry contains a flag EPA
         (which is short for Egress Protection is Active) and 
         a backup path to a backup egress node (say Y) which is configured 
         to protect the egress node. </t>

      <t>In normal operations, the flag EPA in the backup entry 
         for neighbor egress node X is set to 0 (zero).
         The flag EPA is set to 1 (one) when egress node X fails. 
         EPA == 1 means that the egress protection for primary 
         egress node X is active and the backup entry will be used
         to forward the packet with BP for egress node X to 
         backup egress node Y along the backup path.</t> 

      <t>The backup path from the BFR to backup egress node Y is 
         a path that satisfies a set of constraints and 
         does not traverse primary egress node X or 
         any link connected to X. 
         In one implementation, the backup path is represented 
         by the BitPositions for the adjacencies along the backup 
         path.</t>

    </section> <!-- Extensions to BIER-TE BIFT for Egress Protection -->

    <section title="Updated Forwarding Procedure">  
       <t>The forwarding procedure defined in 
          <xref target="RFC9262"/>
          is updated/enhanced for using an extended BIER-TE BIFT 
          to consider the egress protection 
          (i.e., the new backup entry containing EPA and backup path 
          in the BIFT).</t>

       <t>For a multicast packet with the BP in the BitString 
          indicating a BFR-NBR 
          as a primary egress node, the updated forwarding procedure on a BFR
          sends the packet towards the backup egress node of the primary
          egress node if the primary egress node fails. </t>

       <t>It checks whether EPA equals to 1 (one) in the forwarding 
          entry with the BFR-NBR that is the primary egress node. 
          
          If EPA is 1 (i.e., the primary egress node fails and 
          the egress protection for primary egress is active), 
          then the procedure clears two BPs in the packet's BitString and 
          checks whether the backup egress node is not 
          one of the packet's destinations. </t>

       <t>One BP is the BP for the primary egress node and 
          the other is the BP for the forward connected adjacency 
          from the BFR to the primary egress node.
          After these two BPs are cleared in the packet's BitString,
          the packet will not be sent to the failed primary egress node.</t> 

       <t>When the BP for the backup egress node in the packet's 
          BitString is 0, the backup egress node is not 
          one of the packet's destinations. In this case, the procedure 
          adds the backup path to the backup egress node into the packet
          through adding the BPs for the backup path in the packet's 
          BitString. Thus the packet will be sent to the backup egress 
          node along the backup path.</t>

       <t>The updated procedure is described in 
          <xref target="proc4-frr-bift"/>.
          It can also be used by the BFR
          to forward multicast packets in normal operations.
 
<figure anchor="proc4-frr-bift" 
        title="Updated Forwarding Procedure">
  <artwork> <![CDATA[
  Packet = the packet received by BFR;
  FOR each BP k (from the rightmost in Packet's BitString) {
     IF BP k is local decap adjacency (or say BP of the BFR) {
        copies Packet, sends copy's payload to the multicast 
        flow overlay and clears bit k in Packet's BitString
     } ELSE IF BP k is forward connect adjacency of the BFR {
        finds FIB entry for BFR-NBR in BIER-TE BIFT using BP k;
        Clears BP k;
        IF EPA == 1 {//Egress Protection for BFR-NBR/egress is Active
           Clears BP for BFR-NBR in Packet's BitString;
           IF BP for backup egress is 0 in Packet's BitString {
              Adds BPs for backup path into Packet's BitString 
           }
        } //egress removed, backup path to backup egress added
        ELSE {
           Copies Packet and sends the updated copy to BFR-NBR
        }
     }
  }]]></artwork>
</figure> </t>
    </section> <!-- Updated Forwarding Procedure -->

   </section> <!-- "BIER-TE Extensions" --> 


    <section title="Example Application of BIER-TE Egress Protection">
      <t>This section illustrates an example application of 
         BIER-TE Egress Protection on a BFR in a BIER-TE topology 
         in <xref target="bier-top-1"/>.</t>

      <section title="Example BIER-TE Topology">
        <t>An example BIER topology for a BIER-TE sub-domain is shown
           in <xref target="bier-top-1"/>.
           It has 8 nodes/BFRs A, B, C, D, E, F, G and H.

           <figure anchor="bier-top-1" 
           title="Example BIER-TE Topology">
  <artwork> <![CDATA[
                             6'      13'    14'  4 (0:01000)
                    /-----------( G )----------( H )Backup Egress for D
                   /           15'\_______   10'/  \
                  /                _______)____/    \
                 /                /      (_____     (CE) Receiver
                /                /             \    /
      8'   7'  /5'  3'     4'   /9'  17'     16'\  /
( A )--------( B )------------( C )------------( D )Primary Egress
  5(0:10000)   \1'              \11'       18'   1 (0:00001)
                \                \
                 \2'   19'   20'  \12'
                ( E )------------( F )
                  3(0:00100)       2 (0:00010)  ]]></artwork>
</figure>

           Nodes/BFRs D, F, E, H and A are BFERs and have 
           local decap adjacency BitPositions 1, 2, 3, 4, and 5 respectively.
           For simplicity, these BPs are represented by (SI:BitString),
           where SI = 0 and BitString is of 5 bits. 
           BPs 1, 2, 3, 4, and 5 are represented by
           1 (0:00001), 2 (0:00010), 3 (0:00100), 4 (0:01000) and 5 (0:10000)
           respectively. </t>

         <t>The BitPositions for the forward connected adjacencies 
            are represented by i', where i is from 1 to 20. 
            In one option, they are encoded as (n+i), 
            where n is a power of 2 such as 32768.
            For simplicity, these BitPositions are represented 
            by (SI:BitString),
            where SI = (6 + (i-1)/5) and BitString is of 5 bits. 
            BitPositions i' (i from 1 to 20) are represented by
            1'(6:00001), 2'(6:00010), 3'(6:00100), 4'(6:01000), 5'(6:10000),
            6'(7:00001), 7'(7:00010), 8'(7:00100), . . . , 20'(9:10000).</t>

        <t>For a link between two nodes X and Y, 
           there are two BitPositions for two forward connected adjacencies.
           These two forward connected adjacency BitPositions are assigned 
           on nodes X and Y respectively. 
           The BitPosition assigned on X is the forward connected 
           adjacency of Y.
           The BitPosition assigned on Y is the forward connected 
           adjacency of X.</t>

        <t>For example, for the link between nodes B and C in the figure,
           two forward connected adjacency BitPositions 3' and 4' are assigned
           to two ends of the link.
           BitPosition 3' is assigned on node B to B's end of the link. 
           It is the forward connected adjacency of node C.
           BitPosition 4' is assigned on node C to C's end of the link. 
           It is the forward connected adjacency of node B.</t>

        <t>BFER H is configured to protect BFER D on BFR D. 
           Suppose that this information is distributed to BFR D's
           neighbors BFR C and BFR G by IGP. BFR C and BFR G know
           that H is the backup egress to protect the primary 
           egress D.</t>

        <t>Similarly, BFER D is configured to protect BFER H on BFR H;
           BFER F is configured to protect BFER E on BFR E; and
           BFER E is configured to protect BFER F on BFR F. 
           These are not shown in the figure.</t>

       <t>CE is a multicast traffic Receiver, which is dual homed to
          primary egress node D and backup egress node H for 
          protecting primary egress D.
          During normal operations, there is no multicast traffic 
          to CE from backup egress node H and CE receives
          the multicast traffic only from primary egress node D.
          There is no duplicated traffic to receiver CE. 
          This is different from MoFRR in <xref target = "RFC7431"/>,
          where duplicated traffic is sent to both the primary 
          egress D and backup egress H, 
          to which the receiver CE is dual homed. 
          When primary egress node D fails, 
          the multicast traffic is sent to CE from backup egress node H.</t>
      </section> <!-- Example BIER-TE Topology -->


      <section title="BIER-TE BIFT on a BFR">
        <t>Every BFR in a BIER-TE sub-domain/topology has 
           a BIER-TE BIFT. 
           For the BIER-TE topology in <xref target="bier-top-1"/>,
           each of 8 nodes/BFRs A, B, C, D, E, F, G and H 
           has its BIER-TE BIFT for the topology.</t>

        <t>The BIER-TE BIFT on BFR C (i.e. node C) is shown in
           <xref target="bift-bfr-c"/>. </t>

         <t>The 1st forwarding entry in the BIFT will forward a multicast   
            packet with BitPosition 18' to D.</t>
         <t>The 2nd forwarding entry in the BIFT will forward a multicast  
            packet with BitPosition 12' to F.</t>
         <t>The 3rd forwarding entry in the BIFT will forward a multicast  
            packet with BitPosition 10' to H.</t>
         <t>The 4-th forwarding entry in the BIFT will forward a multicast 
            packet with BitPosition 3' to B.

<figure anchor="bift-bfr-c" 
        title="BIER-TE BIFT on BFR C">
  <artwork> <![CDATA[
           +----------------+--------------+------------+
           |  Adjacency BP  |    Action    |  BFR-NBR   |
           | (SI:BitString) |              | (Next Hop) |
           +================+==============+============+
           | 18' (9:00100)  | fw-connected |     D      |
           +----------------+--------------+------------+
           | 12' (8:00010)  | fw-connected |     F      |
           +----------------+--------------+------------+
           | 10' (7:10000)  | fw-connected |     H      |
           +----------------+--------------+------------+
           |  3' (6:00100)  | fw-connected |     B      |
           +----------------+--------------+------------+ ]]></artwork>
</figure> 
       </t>

       <t>The BIER-TE BIFT on BFR D (i.e. node D) is shown in
           <xref target="bift-bfr-d"/>. </t>
       <t>The 1st forwarding entry in the BIFT will forward a multicast  
          packet with BitPosition 17' to C.</t>
       <t>The 2nd forwarding entry in the BIFT will forward a multicast  
          packet with BitPosition 15' to G.</t>
       <t>The 3rd forwarding entry in the BIFT will locally decapsulate  
          a multicast packet with BitPosition 1 and pass a copy of the  
          payload of the packet to the packet's NextProto.

<figure anchor="bift-bfr-d" 
        title="BIER-TE BIFT on BFR D">
  <artwork> <![CDATA[
           +----------------+--------------+------------+
           |  Adjacency BP  |    Action    |  BFR-NBR   |
           | (SI:BitString) |              | (Next Hop) |
           +================+==============+============+
           | 17' (9:00010)  | fw-connected |     C      |
           +----------------+--------------+------------+
           | 15' (8:10000)  | fw-connected |     G      |
           +----------------+--------------+------------+
           |  1  (0:00001)  | local-decap  |            |
           +----------------+--------------+------------+]]></artwork>
</figure>
         </t>

      </section> <!-- BIER-TE BIFT on a BFR -->


      <section title="Extended BIER-TE BIFT on a BFR">
        <t>Each of the BFRs that are neighbors of egress nodes 
           (i.e., BFERs) in a BIER-TE sub-domain/topology has an
           extended BIER-TE BIFT to support protection against
           the failure of every its neighbor egress node. </t>

         <t>For example, the extended BIER-TE BIFT on BFR C is 
            illustrated in <xref target="ep-bift-bfr-c"/>.
            It comprises
            a backup entry for each of its neighbor egress nodes 
            D, F and H. Each of these backup entries contains
            a flag EPA and 
            a backup path to a backup egress node.
            EPA is set to zero in normal operations.
            EPA in the backup entry for neighbor egress node X 
            is set to one when egress node X fails.</t>

         <t>The backup entry of the 1st forwarding entry in the BIFT contains 
            EPA = 0 and backup path {10', 4}. 
            When egress node D fails, the EPA is set to one and 
            the backup entry is used to
            forward a multicast packet with BitPosition 1 for D 
            to D's backup egress node H with BitPosition 4 
            along the backup path.</t>

         <t>The backup entry of the 2nd forwarding entry in the BIFT contains 
            EPA = 0 and backup path {3', 2', 3}. 
            When egress node F fails, EPA is set to one and 
            the backup entry is used to
            forward a multicast packet with BitPosition 2 for F 
            to F's backup egress node E with BitPosition 3 
            along the backup path.

<figure anchor="ep-bift-bfr-c" 
        title="Extended BIER-TE BIFT on BFR C">
  <artwork> <![CDATA[
   +----------------+--------------+----------+-----------------+
   |  Adjacency BP  |    Action    | BFR-NBR  |  Backup Entry   |
   | (SI:BitString) |              |(Next Hop)|(EP, BackupPath) |
   +================+==============+==========+=================+
   | 18' (9:00100)  | fw-connected |    D     |EPA=0, {10', 4}  |
   +----------------+--------------+----------+-----------------+
   | 12' (8:00010)  | fw-connected |    F     |EPA=0, {3', 2',3}|
   +----------------+--------------+----------+-----------------+
   | 10' (7:10000)  | fw-connected |    H     |EPA=0, {18', 1}  |
   +----------------+--------------+----------+-----------------+
   |  3' (6:00100)  | fw-connected |    B     |EPA=0, { }       |
   +----------------+--------------+----------+-----------------+ ]]></artwork>
</figure>
            The backup entry of the 3rd forwarding entry in the BIFT contains 
            EPA = 0 and backup path {18', 1}. 
            When egress node H fails, EPA is set to one and 
            the backup entry is used to
            forward a multicast packet with BitPosition 4 for H 
            to H's backup egress node D with BitPosition 1 
            along the backup path.
        </t>

      </section> <!-- EP-BIRTs and EP-BIFTs on a BFR -->


      <section title="Forwarding using Extended BIER-TE BIFT">
        <t>Suppose that there is a multicast packet 
           with explicit path {7', 4', 18', 12', 2, 1} on BFR A.
           The path is encoded in the BitPositions of the packet.
           BFR A forwards the packet to BFR B according to 
           the forwarding entry for 7' in its extended BIER-TE BIFT.
           BFR B forwards the packet to BFR C according to 
           the forwarding entry for 4' in B's extended BIER-TE BIFT.</t>

        <t>In normal operations, after receiving the packet from BFR B,
           BFR C copies and sends the packet to
           BFR D and BFR F using the forwarding entries for 18' and 12' 
           in the extended BIER-TE BIFT on BFR C respectively.</t>

        <t>Once BFR C detects the failure of egress node D,
           it sets EPA of the backup entry in the 1st forwarding entry to one.
           After receiving the packet from BFR B,
           BFR C copies and sends the packet to D's backup egress node H
           using the backup entry in the forwarding entry for 18' 
           with BFR-NBR D in C's extended BIER-TE BIFT. 
           It copies and sends the packet to F using 
           the forwarding entry for 12' in C's extended BIER-TE BIFT.</t>

        <t>The packet received by BFR C from BFR B contains 
           (SI:BitString) = (0:00011)(8:00010)(9:00100), 
           which represents {18', 12', 2, 1}.
           Since EPA in the backup entry in the forwarding entry with 
           BFR-NBR == D is 1,
           BFR C copies and sends the packet to D's backup egress node H
           in the following steps. </t>

        <t>At first, it obtains the backup entry from the forwarding 
           entry for 18' with BFR-NBR D. 
           EPA == 1 in the backup entry indicates that egress protection 
           for egress node D is active.
           BFR C clears BitPositions 18' and 1 in Packet's BitString 
           and adds the backup path {10', 4} into Packet's BitString.  
           The updated BitString in Packet is (0:01010)(7:10000)(8:00010),
           which represents {12', 10', 4, 2}.
           This lets BFR C copy and send Packet to F and H using the 
           forwarding entries for 12' and 10' in C's extended BIER-TE 
           BIFT respectively.</t>

        <t>When node H receives the packet with BitPosition 4 for H, 
           it decapsulates the packet and passes a copy of the payload 
           of the packet to the packet's NextProto, which sends the 
           payload to the same CE as egress node D sends.</t>

        <t>When node F receives the packet with BitPosition 2 for F, 
           it decapsulates the packet and passes a copy of the payload 
           of the packet to the packet's NextProto, which sends the 
           payload to another CE (not shown in the figure).</t>

      </section> <!-- Forwarding using Extended BIER-TE BIFT -->

    </section> <!-- Example Application of BIER-TE EP -->


    <section anchor="Security" title="Security Considerations">
      <t>TBD.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>No requirements for IANA.</t>
    </section>


    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank people
      for their comments to this work.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
      <?rfc include="reference.RFC.5286"?>
      <?rfc include="reference.RFC.5714"?>
      <?rfc include="reference.RFC.5880"?>
      <?rfc include="reference.RFC.8174"?>
      <?rfc include="reference.RFC.8279"?>
      <?rfc include="reference.RFC.8556"?>
      <?rfc include="reference.RFC.7490"?>

      <?rfc include="reference.RFC.5250"?>
      <?rfc include="reference.RFC.5226"?>
      <?rfc include="reference.RFC.7356"?>
      <?rfc include="reference.RFC.7684"?>
      <?rfc include="reference.RFC.7770"?>
      <?rfc include="reference.RFC.9262"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.8296"?>
      <?rfc include="reference.RFC.8401"?>
      <?rfc include="reference.RFC.8444"?>
      <?rfc include="reference.RFC.7431"?>
      <?rfc include="reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>
      <?rfc include="reference.I-D.ietf-spring-segment-protection-sr-te-paths"?>
      <?rfc include="reference.I-D.eckert-bier-te-frr"?>
    </references>

  </back>

</rfc>
