<?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="exp"
     docName="draft-chen-bier-frr-01"
     ipr="trust200902">
  <front>
    <title abbrev="BIER FRR">BIER Fast ReRoute</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>Huaimo.chen@futurewei.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>Volta Networks</organization>
      <address>
        <postal>
          <street> </street>
          <city>McLean</city>
          <region>VA</region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>xufeng.liu.ietf@gmail.com</email>
      </address>
    </author>

    <date year="2021"/>

    <abstract>
      <t>This document describes a mechanism for fast re-route (FRR) 
         protection against the failure of a node or link in the core of 
         a "Bit Index Explicit Replication" (BIER) domain.
         It does not have any per-flow state in the core.
         For a multicast packet to traverse
         a node in the domain, when the node fails, its upstream 
         hop as a PLR reroutes the packet around the failed node
         once it 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="RFC8279"/> specifies 
         "Bit Index Explicit Replication" (BIER). 
         It provides optimal forwarding of multicast data
         packets through a "multicast/BIER domain". It
         does not require the use of a protocol for explicitly 
         building multicast distribution trees, and it does not
         require intermediate nodes to maintain any per-flow state.</t>

      <t><xref target="I-D.merling-bier-frr"/> proposes a tunnel-based
         fast re-route (FRR) method for protecting a node or link
         in the core of a BIER domain, which is called tunnel-based 
         BIER-FRR. 

         It tunnels BIER packets around the failure to BIER nodes 
         downstream in multicast distribution trees.
         For a (next hop) node failure, it tunnels BIER packets to the 
         next next hop nodes (NNHs).

         The BIFT in every BFR is enhanced to have two forwarding entries
         for every BFER. One is the primary forwarding entry with primary
         NH such as BFR neighbor and primary bit mask, 
         and the other is the backup forwarding entry with backup NH 
         such as NNH and backup bit mask.

         Using one BIFT in a BFR for both normal and backup forwarding
         will save memory.</t>

      <t>In normal operations, the primary forwarding entries are used
         to forward BIER packets. When a failure such as a node failure 
         happens, the backup forwarding entry corresponding to the failure
         and the other primary forwarding entries are used to 
         forward BIER packets. 

         In the BIFT, the primary bit mask in every primary forwarding entry
         is computed before the failure. After the failure, 
         the primary bit mask needs to be recomputed from the changed 
         topology. Before the primary bit mask is recomputed and updated,
         some of BIER packets may be forwarded incorrectly.</t>

      <t>This document describes a mechanism for fast re-route (FRR) 
         protection against the failure of a node or link in the core of 
         a BIER domain, which resolves the above issue.
         It is based on LFA, which is called LFA-based BIER-FRR. 
         On a BFR, there is a FRR BIFT for each of its neighbors,
         which has considered the neighbor failure. 
         There is one forwarding entry for every BFER in any BIFT,
         including normal BIFT and FRR BIFT. 
         This may use more memory.</t>
         
      <t>In normal operations, the normal BIFT is used to 
         forward BIER packets. 
         When a neighbor fails, the BFR as PLR uses the FRR BIFT 
         for the neighbor to forward BIER packets. 
         For a BIER packet to traverse
         the BFR and the failed neighbor,  
         the BFR reroutes the packet 
         around the failed neighbor using the FRR BIFT for the neighbor. 

         For a BIER packet to traverse the BFR and any other neighbors,
         the BFR forwards the packet to its expected next hop neighbors 
         using the forwarding entries with these 
         BFR neighbors in the FRR BIFT.</t>

<!--
      <t>This BIER-FRR does not require intermediate nodes to maintain
         any per-flow state for FRR protection against the failure of 
         a node or link along the flow.</t>
-->

    <section title="Terminology">
      <t>
      <list style="hanging" hangIndent="6">
       <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="LFA:">Loop-Free Alternate.</t>
       <t hangText="RLFA:">Remote LFA.</t>
       <t hangText="DLFA:">Remote LFA with Directed forwarding.</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="SPT-old(R):">The SPT rooted at node R using LSDB 
          before X fails (i.e., old LSDB).</t>
       <t hangText="SPT-new(R, X):">The SPT rooted at node R using LSDB 
          without X after X fails (i.e., new LSDB).</t>

       <t hangText="P-Space P(R,X):">The set of nodes that are reachable 
          from R without going through X. In other words, it is the set of
          nodes that are not downstream of X in SPT-old(R).</t>
       <t hangText="Extended P-Space P'(R,X):">The set of nodes that are 
          reachable from R or a neighbor of R, without going through X.</t>

       <t hangText="Q-Space Q(D,X):">The set of nodes that do not use X 
          to reach destination D using the old LSDB. </t>

       <t hangText="PQ node(R,X):">
          A member of both the P-Space P(R, X) (or the extended
          P-Space P'(R, X)) and the Q-Space (D, X).</t>

      </list></t>
    </section> <!-- Terminology -->

    </section> <!-- Introduction -->



    <section title="BIER FRR Solution">     
       <t>A Bit-Forwarding Router (BFR) in a BIER sub-domain builds 
          and maintains a "FRR Bit Index Routing Table" (FRR-BIRT)
          for each of its BFR Neighbors (BFR-NBRs) 
          to provide BIER-FRR.
          The BFR builds each FRR-BIRT based on a BIRT defined in 
          <xref target="RFC8279"/>.
          A "FRR Bit Index Forwarding Table" (FRR-BIFT) is derived 
          from a FRR-BIRT in the same way as a BIFT is derived from
          a BIRT, which is defined in <xref target="RFC8279"/>.</t>

       <t>The forwarding procedure defined in <xref target="RFC8279"/>
          is enhanced/updated for FRR-BIFTs.  
          Once the BFR as a PLR detects the failure of its BFR-NBR X,
          it uses the FRR-BIFT for X to forward packets with
          BIER headers to get around failed X according to the 
          updated/enhanced forwarding procedure.</t> 

      <section title="Overview of BIER forwarding"> 
       <t>This section briefs the BIRT, BIFT and forwarding procedure 
          defined in <xref target="RFC8279"/>.</t>
    
       <t>There is a "Bit Index Routing Table" (BIRT) for a BIER sub-domain
          on a BFR.
          The BIRT maps the BFR Identifier (BFR-id) (in the sub-domain)  
          of a  Bit-Forwarding Egress Router (BFER) to the BFR-prefix of 
          that BFER, and 
          to the BFR-NBR on the shortest path to that BFER.
          In other words, 
          the BIRT has a route or say a next hop (i.e., BFR-NBR on the path) 
          to every BFER.</t> 

       <t>From the BIRT on the BFR, a "Bit Index Forwarding Table" (BIFT) 
          is derived.
          In addition to having a route to a BFER in each row of the BIFT
          which is the same as the BIRT,  
          it has a "Forwarding Bit Mask" (F-BM) in its each row.
          For the rows in the BIRT that have the same SI and the same BFR-NBR,
          the F-BM for each of these rows in the BIFT is 
          the logical OR of the BitStrings of these rows.</t>

       <t>This BIFT is programmed into the data plane and used to forward
          a packet with a BIER header. 
          The header contains SI, BitString, BitStringLength, and sub-domain.</t> 

       <t>When a BFR receives a packet, 
          for each BFER k (from the rightmost to the leftmost) 
          represented in the SI and BitString of the packet,
          if BFER k is the BFR itself, the BFR 
          copies the packet, sends the copy to the multicast flow overlay
          and clears bit k in the original packet; otherwise
          the BFR finds the row (i.e., forwarding entry) in the BIFT 
          for the sub-domain
          using the SI and BitString as the key or say index,

          and then copies, updates and forwards the packet to 
          the BFR-NBR (i.e., the next hop) indicated by the row 
          (i.e., forwarding entry).</t> 

       <t>After copying the packet and before forwarding it to the BFR-NBR,
          the packet's BitString is updated by ANDing it with the F-BM 
          in the forwarding entry (i.e., PacketCopy->BitString &amp;= F-BM).</t>

       <t>After forwarding the updated packet to a BFR-NBR and 
          before forwarding the original packet to another BFR-NBR, 
          the original packet's BitString is changed by ANDing it with the
          INVERSE of the F-BM (i.e., Packet->BitString &amp;= ~F-BM).</t>
      </section> <!-- Overview of BIER forwarding -->

 
      <section title="FRR Bit Index Routing Tables">    
       <t>Each BFR in a BIER sub-domain builds and maintains
          a number of "FRR Bit Index Routing Tables" (FRR-BIRTs).         
          There is a FRR-BIRT for each BFR-NBR of the BFR.
          The BFR builds each FRR-BIRT based on its BIRT.
          It has the same format as the BIRT.</t> 

       <t>The FRR-BIRT for BFR-NBR X of the BFR considers
          the failure of X and
          maps the BFR-id (in the sub-domain) of a BFER 
          to the BFR-prefix of that BFER, and 
          to BFR-NBR N on the path to that BFER.
          In other words, the FRR-BIRT has a route or say a next hop 
          (i.e., BFR-NBR N on the path, where N is not X) 
          to every BFER when BFR-NBR X fails.</t> 

       <t>The BFR may build the FRR-BIRT for BFR-NBR X 
          by copying its BIRT to the FRR-BIRT first, and then
          change the next hop with value BFR-NBR X in the FRR-BIRT to 
          a backup next hop (BNH) to protect against the failure of X.
          
          In other wards, for the BFR-id of a BFER in the FRR-BIRT for BFR-NBR X, 
          if the next hop BFR-NBR on the path to the BFER is X, 
          it is changed to a BNH 
          when there is a BNH on a backup path to the BFER without 
          going through X and the link from the BFR to X.</t>

       <t>If there is not any BNH to a BFER to protect against the failure of X,
          the next hop BFR-NBR X to the BFER in the FRR-BIRT for BFR-NBR X 
          is changed to NULL. 

          For a multicast packet having the BFER as one of its destinations,
          if the next hop BFR-NBR to the BFER is NULL,
          the BFR does not send the packet to the next hop BFR-NBR NULL 
          but drops it when X fails.</t>

      <t>Note: In another option, 
         the next hop BFR-NBR X to the BFER in the FRR-BIRT for BFR-NBR X 
         keeps unchanged when there is not any BNH to the BFER to protect 
         against the failure of X. 

         In this case, 
         for a multicast packet having the BFER as one of its destinations,
         the BFR sends the packet to X when X fails.</t>

       <t>In one implementation, the BNH is the Loop-Free 
          Node-Protecting Alternate defined in <xref target="RFC5286"/>
          to protect against the failure of X and link from the BFR to X.
          In another implementation, the BNH is the virtual 
          Loop-Free Alternate (LFA), i.e., PQ node, 
          defined in <xref target="RFC7490"/>. 
          In a special case, a PQ node is a Loop-Free 
          Node-Protecting Alternate defined in <xref target="RFC5286"/>.
          </t>
      </section> <!-- FRR Bit Index Routing Tables -->


      <section title="FRR Bit Index Forwarding Tables">  
       <t>From each FRR-BIRT on the BFR, a "FRR Bit Index Forwarding Table"  
          (FRR-BIFT) is derived.
          In addition to having a route to a BFER in each row of the FRR-BIFT
          which is the same as the FRR-BIRT,  
          it has a "Forwarding Bit Mask" (F-BM) in its each row.
          For the rows in the FRR-BIRT that have the same SI and the same BFR-NBR,
          the F-BM for each of these rows in the FRR-BIFT is 
          the logical OR of the BitStrings of these rows.</t>

       <t>This FRR-BIFT is programmed into the data plane and 
          is not used to forward any packet in normal operations.
          It is activated to forward a packet with a BIER header
          once the BFR detects the failure of BFR-NBR. 
          The header contains SI, BitString, BitStringLength, 
          and sub-domain.</t> 
      </section> <!-- FRR Bit Index Forwarding Tables -->


      <section title="Updated Forwarding Procedure">  
       <t>The forwarding procedure defined in <xref target="RFC8279"/>
          is updated/enhanced for a FRR-BIFT to consider the case 
          where the next hop BFR-NBR to a BFER is NULL.

          For a multicast packet with the BitString indicating a BFER 
          as one of its destinations, the updated forwarding procedure
          checks whether the next hop BFR-NBR to the BFER 
          in the FRR-BIFT is NULL.
          If it is NULL, the procedure will not send the packet to 
          this next hop BFR-NBR NULL but drop the packet.</t>

       <t>The updated procedure is described in 
          <xref target="proc4-frr-bift"/>.
          It is used with a FRR-BIFT for BFR-NBR X 
          on a BFR to forward multicast packets when X fails. 
          It can also be used with a BIFT on 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 BFER k (from the rightmost in Packet's BitString) {
      IF BFER k is the BFR itself {
          copies Packet, sends the copy to the multicast 
          flow overlay and clears bit k in Packet's BitString
      } else {
          finds the row in the FRR-BIFT for the sub-domain using 
          Packet's SI and BitString as the key/index
          IF BFR-NBR in the row is not NULL {
              Copies Packet, updates the copy's BitString by ANDing
              it with F-BM in the row, sends updated copy to BFR-NBR               
          } // BFR-NBR == NULL, not sent Packet to BFR-NBR
          updates Packet's BitString by ANDing it with the INVERSE
          of the F-BM in the row
      }
  }]]></artwork>
</figure> </t>
      </section> <!-- Updated Forwarding Procedure -->


      <section title="Switching between FRR and Normal Forwarding">
       <t>The FRR-BIFTs will be pre-computed and installed ready 
          for activation when a failure is detected.

          Once the BFR detects the failure of its BFR-NBR X,
          it activates the FRR-BIFT for X to forward packets with BIER headers 
          and de-activates its BIFT.

          After activation of the FRR-BIFT, it remains in effect
          until it is no longer required.</t>

       <t>In general, when the routing protocol has re-converged 
          on the new topology taking into account the failure of X, 
          the BIRT is re-computed using the updated LSDB and
          the BIFT is re-derived from the BIRT.

          Once the BIFT is installed ready for activation, 
          it is activated to forward packets with BIER headers
          and the FRR-BIFT for X is de-activated. </t>

       <t>From the new topology, the BFR computes/re-computes 
          the FRR-BIRT for each BFR-NBR Y of the BFR and 
          the FRR-BIFT for Y is derived/re-derived from the FRR-BIRT for Y.

          The FRR-BIFT is installed/re-installed ready 
          for activation when Y fails.</t>
      </section> <!-- Switching between FRR and Normal -->
    </section> <!-- BIER FRR Solution -->


    <section title="Example Application of BIER FRR">
      <t>This section illustrates an example application of 
         BIER FRR on a BFR in a BIER topology 
         in <xref target="bier-top-1"/>.</t>

      <section title="Example BIER Topology">
        <t>An example BIER topology for a BIER sub-domain is shown
           in <xref target="bier-top-1"/>.

           It has 8 nodes/BFRs A, B, C, D, E, F, G and H. 
           Each of the links connecting these nodes/BFRs has a cost. 
           The link cost of 1 is default and is not indicated in the figure.
           The link cost of other value such as 2 is indicated in the figure.

           <figure anchor="bier-top-1" 
           title="Example BIER Topology">
  <artwork> <![CDATA[
                                                          4 (0:01000)
                          /-----------( G )-------------( H )
                        2/              2\________       /
                        /                  _______)_____/
                       /                  /       (______
                      /                  /               \
  ( A )------------( B )--------------( C )-------------( D )
    5 (0:10000)       \                  \                1 (0:00001)
                      2\                  \
                        \                  \
                       ( E )--------------( F )
                         3 (0:00100)        2 (0:00010)  ]]></artwork>
</figure>

           Nodes/BFRs D, F, E, H and A are BFERs and have 
           BFR-ids 1, 2, 3, 4, and 5 respectively.
           For simplicity, these BFR-ids are represented by (SI:BitString),
           where SI = 0 and BitString is of 5 bits. 
           BFR-ids 1, 2, 3, 4, and 5 are represented by
           (0:00001), (0:00010), (0:00100), (0:01000) and (0:10000)
           respectively. </t>
      </section> <!-- Example BIER Topology -->


      <section title="BIRT and BIFT on a BFR">
        <t>Every BFR in a BIER sub-domain/topology builds and maintains 
           a Bit Index Routing Table (BIRT). 
           For the BIER topology in <xref target="bier-top-1"/>,
           each of 8 nodes/BFRs A, B, C, D, E, F, G and H 
           builds and maintains a BIRT using the LSDB for the topology.</t>

        <t>The BIRT built on BFR B (i.e. node B) is shown in
           <xref target="birt-bfr-b"/>.
 
<figure anchor="birt-bfr-b" 
        title="BIRT on BFR B">
  <artwork> <![CDATA[
           +----------------+--------------+------------+
           |     BFR-id     |  BFR-Prefix  |  BFR-NBR   |
           | (SI:BitString) | of Dest BFER | (Next Hop) |
           +================+==============+============+
           |  1 (0:00001)   |     D        |     C      |
           +----------------+--------------+------------+
           |  2 (0:00010)   |     F        |     C      |
           +----------------+--------------+------------+
           |  3 (0:00100)   |     E        |     E      |
           +----------------+--------------+------------+
           |  4 (0:01000)   |     H        |     C      |
           +----------------+--------------+------------+
           |  5 (0:10000)   |     A        |     A      |
           +----------------+--------------+------------+ ]]></artwork>
</figure>
            The 1st row in the BIRT indicates that the next hop BFR-NBR
            on the shortest path to BFER D with BFR-id 1 is BFR C.</t>
         <t>The 2nd row in the BIRT indicates that the next hop BFR-NBR
            on the shortest path to BFER F with BFR-id 2 is BFR C.</t>
         <t>The 3rd row in the BIRT indicates that the next hop BFR-NBR
            on the shortest path to BFER E with BFR-id 3 is BFR E.</t>
         <t>The 4-th row in the BIRT indicates that the next hop BFR-NBR
            on the shortest path to BFER H with BFR-id 4 is BFR C.</t>
         <t>The 5-th row in the BIRT indicates that the next hop BFR-NBR
            on the shortest path to BFER A with BFR-id 5 is BFR A.</t>


         <t>From this BIRT on BFR B, 
            a Bit Index Forwarding Table (BIFT) is derived. 
            This BIFT is shown in
            <xref target="bift-bfr-b"/>. </t>

         <t>The 1st, 2nd and 4-th rows in the BIRT have 
            the same SI = 0 and next hop BFR-NBR = C.
            The F-BM for each of these three rows in the
            BIFT is the logical OR of the BitStrings of these rows,
            which is 01011 (00001 OR 00010 OR 01000 = 01011).</t>

         <t>The F-BM for 3rd row in the BIFT is 00100. 
            The F-BM for 5-th row in the BIFT is 10000.

<figure anchor="bift-bfr-b" 
        title="BIFT on BFR B">
  <artwork> <![CDATA[
              +----------------+---------+------------+
              |     BFR-id     |  F-BM   |  BFR-NBR   |
              | (SI:BitString) |         | (Next Hop) |
              +================+=========+============+
              |  1 (0:00001)   |  01011  |     C      |
              +----------------+---------+------------+
              |  2 (0:00010)   |  01011  |     C      |
              +----------------+---------+------------+
              |  3 (0:00100)   |  00100  |     E      |
              +----------------+---------+------------+
              |  4 (0:01000)   |  01011  |     C      |
              +----------------+---------+------------+
              |  5 (0:10000)   |  10000  |     A      |
              +----------------+---------+------------+ ]]></artwork>
</figure>
         </t>

      </section> <!-- BIRT and BIFT on a BFR -->


      <section title="FRR-BIRTs and FRR-BIFTs on a BFR">
        <t>Every BFR in a BIER sub-domain/topology builds and maintains 
           a number of FRR Bit Index Routing Tables (FRR-BIRTs). 
           For the BIER topology in <xref target="bier-top-1"/>,
           each of 8 nodes/BFRs A, B, C, D, E, F, G and H 
           builds and maintains a number of FRR-BIRTs using the LSDB 
           for the topology for its every BFR-NBR.</t>

        <t>For example, BFR B (i.e., node B) in the BIER topology
           builds and maintains four FRR-BIRTs for its four BFR-NBRs
           (BFR C, BFR E, BFR A and BFR G) respectively. 
           The FRR-BIRT for BFR C built by BFR B is shown in
           <xref target="frr-birt4c-bfr-b"/>.
 
<figure anchor="frr-birt4c-bfr-b" 
        title="FRR BIRT for BFR C on BFR B">
  <artwork> <![CDATA[
           +----------------+--------------+------------+
           |     BFR-id     |  BFR-Prefix  |  BFR-NBR   |
           | (SI:BitString) | of Dest BFER | (Next Hop) |
           +================+==============+============+
           |  1 (0:00001)   |     D        |     G      |
           +----------------+--------------+------------+
           |  2 (0:00010)   |     F        |     E      |
           +----------------+--------------+------------+
           |  3 (0:00100)   |     E        |     E      |
           +----------------+--------------+------------+
           |  4 (0:01000)   |     H        |     G      |
           +----------------+--------------+------------+
           |  5 (0:10000)   |     A        |     A      |
           +----------------+--------------+------------+ ]]></artwork>
</figure>
            The 1st row in the FRR-BIRT indicates that the next hop BFR-NBR
            on the path to BFER D with BFR-id 1 is BFR G. 
            G is the Loop-Free Node-Protecting Alternate defined 
            in <xref target="RFC5286"/>
            to protect against the failure of C and link from B to C. </t>
         <t>The 2nd row in the FRR-BIRT indicates that the next hop BFR-NBR
            on the path to BFER F with BFR-id 2 is BFR E.
            E is the Loop-Free Node-Protecting Alternate defined 
            in <xref target="RFC5286"/>
            to protect against the failure of C and link from B to C.</t>
         <t>The 3rd row in the FRR-BIRT indicates that the next hop BFR-NBR
            on the path to BFER E with BFR-id 3 is BFR E.</t>
         <t>The 4-th row in the FRR-BIRT indicates that the next hop BFR-NBR
            on the path to BFER H with BFR-id 4 is BFR G.
            G is the Loop-Free Node-Protecting Alternate defined 
            in <xref target="RFC5286"/>
            to protect against the failure of C and link from B to C.</t>
         <t>The 5-th row in the FRR-BIRT indicates that the next hop BFR-NBR
            on the path to BFER A with BFR-id 5 is BFR A.</t>


         <t>From this FRR-BIRT for BFR C on BFR B, 
            a FRR Bit Index Forwarding Table (FRR-BIFT) is derived. 
            This FRR-BIFT for BFR C is shown in
            <xref target="frr-bift4c-bfr-b"/>. </t>

         <t>The 1st and 4-th rows in the FRR-BIRT have 
            the same SI = 0 and next hop BFR-NBR = G.
            The F-BM for each of these two rows in the
            FRR-BIFT is the logical OR of the BitStrings of these rows,
            which is 01001 (00001 OR 01000 = 01001).

<figure anchor="frr-bift4c-bfr-b" 
        title="FRR BIFT for BFR C on BFR B">
  <artwork> <![CDATA[
              +----------------+---------+------------+
              |     BFR-id     |  F-BM   |  BFR-NBR   |
              | (SI:BitString) |         | (Next Hop) |
              +================+=========+============+
              |  1 (0:00001)   |  01001  |     G      |
              +----------------+---------+------------+
              |  2 (0:00010)   |  00110  |     E      |
              +----------------+---------+------------+
              |  3 (0:00100)   |  00110  |     E      |
              +----------------+---------+------------+
              |  4 (0:01000)   |  01001  |     G      |
              +----------------+---------+------------+
              |  5 (0:10000)   |  10000  |     A      |
              +----------------+---------+------------+ ]]></artwork>
</figure>
            The 2nd and 3rd rows in the FRR-BIRT have 
            the same SI = 0 and next hop BFR-NBR = E.
            The F-BM for each of these two rows in the
            FRR-BIFT is the logical OR of the BitStrings of these rows,
            which is 00110 (00010 OR 00100 = 00110).</t>

         <t>The F-BM for 5-th row in the FRR-BIFT is 10000.</t>

         <t>The number of entries in a FRR BIFT is the number of BFERs.
            Each FRR BIFT on a BFR can be compressed through 
            combining all the entries with the same BFR-BNR and 
            F-BM into one entry. The number of entries in a compressed 
            FRR BIFT is the number of neighbors of the BFR minus one.</t>

         <t>For example, the compressed FRR-BIFT for BFR C on BFR B
            is shown in
            <xref target="compressed-frr-bift4c-bfr-b"/>. 
            The number of entries in it is three, 
            which equals the number (four)
            of neighbors of BFR B minus one. 

<figure anchor="compressed-frr-bift4c-bfr-b" 
        title="Compressed FRR BIFT for BFR C on BFR B">
  <artwork> <![CDATA[
              +----------------+---------+------------+
              |     BFR-id     |  F-BM   |  BFR-NBR   |
              | (SI:BitString) |         | (Next Hop) |
              +================+=========+============+
              | 1, 4 (0:01001) |  01001  |     G      |
              +----------------+---------+------------+
              | 2, 3 (0:00110) |  00110  |     E      |
              +----------------+---------+------------+
              |  5 (0:10000)   |  10000  |     A      |
              +----------------+---------+------------+ ]]></artwork>
</figure>
        For a BIER packet with a BFR-ID as a destination, 
        the entry containing the BFR-ID is used
        to forward the packet. 
</t>

      </section> <!-- FRR-BIRTs and FRR-BIFTs on a BFR -->


      <section title="Forwarding using FRR-BIFT">
        <t>Suppose that there is a multicast traffic from
           BFR A as ingress/BFIR to egresses/BFERs D, F, E and H.
           For every packet of the traffic, after receiving it, 
           BFR A adds a BIER header into the packet and 
           sends the packet with the BIER header to BFR B.
           The BIER header contains (SI:BitString) = (0:01111) for 
           egresses/BFERs D, F, E and H.</t>

        <t>In normal operations, after receiving the packet from BFR A,
           BFR B copies, updates and sends the packet to
           BFR C and BFR E using the BIFT on BFR B according to
           the forwarding procedure defined in 
           <xref target="RFC8279"/>.</t>

        <t>Once BFR B detects the failure of its BFR-NBR X,
           after receiving the packet from BFR A,
           BFR B copies, updates and sends the packet 
           using the FRR-BIFT for X on BFR B to avoid X and link from B to X 
           according to the forwarding procedure defined in 
           <xref target="RFC8279"/>.</t>

        <t>For example, 
           once BFR B detects the failure of its BFR-NBR C,  
           after receiving the packet from BFR A,
           BFR B copies, updates and sends the packet to 
           BFR G and BFR E using the FRR-BIFT for BFR C on BFR B 
           to avoid C and link from B to C.</t>

        <t>The packet received by BFR B from BFR A contains 
           (SI:BitString) = (0:01111). 
           The rightmost one bit in BitString is bit 1.
           For BFER 1 (0:00001) (i.e., BFR D as BFER), 
           BFR B gets the 1st row (i.e., forwarding entry) in the 
           FRR-BIFT for BFR C. 
           The next hop BFR-NBR is G in the row.
           BFR B copies, updates and forwards the packet to G.</t>

        <t>The packet sent to G contains the updated 
           BitString = 01001, 
           which is 01111 &amp; F-BM in the row = 01111 &amp; 01001.</t>

        <t>After sending the packet to G, 
           BFR B updates the original packet by ANDing its BitString with the
           INVERSE of the F-BM in the row. 
           The updated BitString = 00110,
           which is 01111 &amp; ~F-BM in the row = 01111 &amp; 00110.</t> 
       
        <t>For the packet containing BitString = 00110, 
           the rightmost one bit in BitString is bit 2.
           For BFER 2 (0:00010) (i.e., BFR F as BFER), 
           BFR B gets the 2nd row (i.e., forwarding entry) in the 
           FRR-BIFT for BFR C. 
           The next hop BFR-NBR is E in the row.
           BFR B copies, updates and forwards the packet to E.</t>
        <t>The packet sent to E contains the updated 
           BitString = 00110, 
           which is 00110 &amp; F-BM in the 2nd row = 00110 &amp; 00110.</t>

        <t>After sending the packet to E, 
           BFR B updates the original packet by ANDing its BitString with the
           INVERSE of the F-BM in the 2nd row. 
           The updated BitString = 00000,
           which is 00110 &amp; ~F-BM in the row = 00110 &amp; 11001.</t>

        <t>The updated packet has BitString without any one bit.
           BFR B finishes forwarding the packet from A to D, F, E and H.</t>

      </section> <!-- Forwarding using FRR-BIFT -->

    </section> <!-- Example Application of BIER FRR -->


    <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 Jeffrey Zhang, Daniel Merling
         and Geng Xuesong
         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"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.8296"?>
      <?rfc include="reference.RFC.8401"?>
      <?rfc include="reference.RFC.8444"?>
      <?rfc include="reference.I-D.merling-bier-frr"?>
      <?rfc include="reference.I-D.ietf-rtgwg-segment-routing-ti-lfa"?>
      <?rfc include="reference.I-D.ietf-spring-segment-protection-sr-te-paths"?>
    </references>

  </back>

</rfc>
