A Framework for Fast Reroute with Bit Index Explicit Replication (BIER-FRR)

2.1. Benefits

BIER is a novel method that allows to simplify and scale the deployments of multicast services significantly over widely deployed technologies like [PIM-SM] for IP networks including SRv6 networks or [mLDP] for MPLS or SR-MPLS networks. The key novelty of BIER is that it is stateless whereas the prior mechanisms are stateful.¶

BIER-FRR allows to achieve fundamentally the same so-called "sub 50msec" recovery from link or node failure that [IP-FRR] achieves the same networks for unicast traffic. Stateful multicast mechanisms including [PIM-SM] and [mLDP] can not support FRR directly. Instead, they must be combined with prior mechanisms to achieve link-protection (such as [RSVP-TE] with [RFC4090] or explicit paths with SR). In summary, link-protection with these pre-existing mechanisms is more complex and less efficient, and node-protection is mostly considered infeasible because of the involved complexity and excess traffic it causes.¶

BIER-FRR likely allows for the most efficient and simple multicast FRR because it fundamentally operates like unicast, except that a BIER packet does not indicate only one destination but a list of multiple packets, allowing for each router to perform unicast like forwarding plus whenever necessary replication of the packet to any outgoing interface through which one or more of these destinations need to be reached.¶

The following sections detail these summaries.¶

2.2. Introduction

The protection level offered by BIER-FRR can be either link protection or node protection. This is like in IP FRR and both of them can co-exist.¶

Link protection is limited to safeguarding against link failures and is simpler to implement but will not be effective if a BFR neighbor fails.¶

Node protection, while more complex, also guards against the failure of BFRs. The choice of backup strategy determines the selection of backup forwarding entries.¶

As in IP FRR, one would typically use node protection and apply link-protection only when the next-hop node is the actual destination (BFER), so that only link-protection makes sense.¶

The followin introductory text explains the two fundamental approaches to BIER-FRR, one being tunnel-based BIER-FRR, and the other being LFA-based BIER-FRR.¶

3.1. Reference Example with BIER forwarding table (BIFT)

[RFC8279], Figure 3, specifies the BIER forwarding conceptually through the structure of the Bit Index Forwarding Table (BIFT). It is summarized here for convenience and to describe the FRR options in the following sections.¶

Figure 5 shows a simple topology used to re-summarize BIER forwarding as well as the FRR options. We look at the forwarding table on R2 and the possible failures of its downstream BFR-NBR R3,R4,R5. R6,R7,R8,R9,R10,R11 are BFER and thus have bits in the bitstring of BIER packets.¶

Assuming the BIFT on R2 was created with the help of a normal shortest path routing protocol, it would look as shown in Figure 6.¶

Each line of the BIFT is an entry for one BFER identified in this represenation by it's BFR-id in the first colum. F-BM is a bitstring represented by the BFR-id included in it. The F-BM exists to suppress multiple copies to the same downstream BFR-NBR. The BFR-NBR is the third colum.¶

In result, a BIER packet whose bitstring indicates R6,R7,R8,R9,R10,R11 would be replicated by R2 into one BIER packet to R3 with a bitstring indicating R6,R7, one BIER packet to R4 indicating R8,R9 and one BIER packet to R5 indicating R10,R11. This happens according to [RFC8279] through the standard BIER forwarding code as shown in Figure 7, copied from [RFC8279], Figure 4. The bitstring of each of the copies only contains a subset of BFER each because of the "&" operation of the pseudocode driven by the BIFT entries F-BM field.¶

void ForwardBitMaskPacket (Packet)
   {
       SI=GetPacketSI(Packet);
       Offset=SI*BitStringLength;
       for (Index = GetFirstBitPosition(Packet->BitString); Index ;
            Index = GetNextBitPosition(Packet->BitString, Index)) {
           F-BM = BIFT[Index+Offset]->F-BM;
           if (!F-BM) continue;
           BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
           PacketCopy = Copy(Packet);
           PacketCopy->BitString &= F-BM;
           PacketSend(PacketCopy, BFR-NBR);
           Packet->BitString &= ~F-BM;
       }
   }

The following three sections introduce three different Forwarding Models for BIER with FRR and their associated modified or extended BIFTs. These three models result not only in different complexities of implementation, but also in three different outcomes (packets replicated) in the case of failures of one of the three neighbors from R2: R3, R4 or R5.¶

Because of differences in outcome, operators need to be aware which model is actually employed by a BFR so that they can validate whether the observed behavior matches the expected behavior (routing, BFR are not malfunctioning), and to be able to do capacity planning, especially under FRR failures - they need to be able to simulate which links/path will have how much additional, FRR re-routed BIER traffic under failures.¶

These models do give good indication how easy or complex implementations are, but they are far from being explicit implementation suggestions.¶

These three models are likely not all possible models how FRR for BIER can be supported through modified or extended BIFT, but not only do they show likely three significantly interesting option, instead, the way they are specified here are also meant to be examples of the type of documentation necessary when implementing yet another model. It simply follows and extends the approach used by [RFC8279].¶

3.2. BIFT with adjacency FRR (BIER-aFRR)

In the BIER-aFRR model, FRR is modelled with no changes to the BIER forwarding/replication algorithm shown in Figure 7. Instead, it leverages the same approach as unicast FRR, enhancing only the neighbor information to which a packet is to be sent, as shown in Figure 8.¶

To emphasize that BIER forwarding stays unchanged, the FRR behavior is solely modelled inside the PacketSend procedure as shown in Figure 9.¶

void PacketSend(PacketCopy, bfrnbr)
    {
        if(bfrnbr == LFA(primary, backup)) {
            if(IsUp(primary) {
                PacketSend(PacketCopy, primary)
            } else {
                PacketSend(PacketCopy, backup)
            }
        } else {
           ... pre-existing non-aFRR forwarding...
        }
    }

This simple pseudocode shows only support for an aFRR adjacency that is equivalent to unicast LFA, because this is the only option required in Example 5. When the primary BFR-NBR is down, the BIER packet is simply sent to the backup BFR neighbor which is another directly connected BFR neighbor. When remote LFA or TI-LFA adjacencies are required due to topology as explained above, the code and BIFT entry options accordingly need to be enhanced with options expressing such LFA adjacencies with additional encapsulations.¶

It should be possible to share pre-existing unicast LFA code (including such remote LFA and TI-LFA code) for this option, so BFER-uFRR should be the option with the least amount of new development and most sharing with unicast FRR.¶

When using aFRR with the example BIFT, the aforementioned BIER packet to R6,R7,R8,R9,R10,R11 would always send two packet copies to one of the two remaining neighbors out of R3,R4,R5, if one of the three neighbors is down.¶

If R3 is down, R1 would first send a copy for R6,R7 towards R4 in result of "LFA(R3,R4)" in the R6 BIFT entry - and R3 being down. It then sends the second copy for R8,R9 towards R4 in result of "LFA(R4,R3)" in the R8 BIFT entry - and R4 being up. Finally it sends a copy for R10,R11 towards R5 in result of "LFA(R5,R4)" and R5 being up.¶

Note that BIER-aFRR can not support FRR for all topologies without a workaround that introduces multiple copies across the same neighbors even in the non-FRR case. See Section 3.5.¶

3.3. BIFT with backup FBM (BIER-bFRR)

In the BIER-bFRR model, FRR is modelled to overcome some of the duplicate packets sent to neighbors when another neighbor fails as shown above as well as the aforementioned issue discussed in Section 3.5. These improvements come at the expense of added complexity in the actual BIER forwarding/replication procedure for FRR.¶

The BIER-bFRR extended BIFT for Example 5 is shown in Figure 10, the forwarding code for BIER with bFRR is shown in Figure 11, the four additional lines of code compared to Figure 7 are shown with the comment "bFRR".¶

Functionally, bFRR simply differs from aFRR in that it allows for a different F-BM to be used when the BFR-NBR is not Up, so that the packet instead has to be sent to the backup BFR-NBR. Because the applying of a BFM to a bitstring is not something applicable to a unicast packet, the bFRR code is hence shown as part of the BIER forwarding loop in the pseudocode.¶

The Backup BFR-NBR is called BBFR-NBR, and the Backup F-BM is called BF-BM in the bFRR enhanced BIFT.¶

void ForwardBitMaskPacket (Packet)
   {
       SI=GetPacketSI(Packet);
       Offset=SI*BitStringLength;
       for (Index = GetFirstBitPosition(Packet->BitString); Index ;
            Index = GetNextBitPosition(Packet->BitString, Index)) {
           F-BM = BIFT[Index+Offset]->F-BM;
           if (!F-BM) continue;
           BFR-NBR = BIFT[Index+Offset]->BFR-NBR;
           if(!IsUp(BFR-NBR) {                          ! bFRR
               F-BM = BIFT[Index+Offset]->BF-BM;        ! bFRR
               BFR-NBR = BIFT[Index+Offset]->BBFR-NBR;  ! bFRR
           }                                            ! bFRR
           PacketCopy = Copy(Packet);
           PacketCopy->BitString &= F-BM;
           PacketSend(PacketCopy, BFR-NBR);
           Packet->BitString &= ~F-BM;
       }
   }

Assuming again as in before for BIER-aFRR a BIER packet to R6,R7,R8,R9,R10,R11.¶

Whereas in BIER-aFRR in Example 5, when R3 was not Up, two packet copies would be sent to R4, one for R6,R7 that should have gone to R3, and another packet copy for R8,R9, which is independent of whether or not R3 is Up or not, in BIER-bFRR this can be optimized because of BB-FM. If R3 is down, the packet copy created because of the BIFT entry for R6 and sent to R4 will include all bits from BB-FM for R6, which includes R6,R7,R8,R9. When then the BIFT entry for R8 and R9 are examined, then their bits have already been reset in the "Packet->BitString". Hence no duplicate packet copies are sent towards R4.¶

However, this BB-FM optimization does not help to avoid duplicate packets to R4 in the case of R5 not being Up. Even though BB-FM makes it look as if the same benefit as for a failure of R3 could happen, this BB-FM is insubstantial because of the sequential processing of the BIFT entries by ForwardBitMaskPacket. The BIFT entry for R8 will have already caused one Packet copy for R8, R9 to be sent to R4, so when the BIFT entry for R10/R11 are examined, a second packet copy for R10,R11 needs to be made towards R4.¶

As a rule of thumb, BIER-bFRR allows for the BB-FM to send to the same BFER as indicated by the B-FM, but also to include the additional bits from the B-FM of BIFT entries where the BBFR-NBR is the BFR-NBR, but but that optimization only reduces duplicate packet copies when the failed BFR-NBR BIFT entry is earlier in the BIFT than the BIFT entries where the BBFR-NBR is the actual BFR-NBR. In cases like Example 5 where two or more BFR-NBR like R3 and R4 mutually protect each other (are BBFR-NBR for one another), it is never possible to avoid packet duplication due to the way the BIFT operates sequentially.¶

Note again, that elimination of packet duplication is not the only reason for BIER-bFRR, see Section 3.5.¶

3.4. BIFT with sorted backup FBM (BIER-sbFRR)

To overcome the problem of BIER-bFRR that it can not avoid unnecessary duplicate packets to one BFR-NBR when another BFR-NBR is down (in all cases), as described above, the simple logical model option is to loop across the bit indices of the BIFT not in their numerical order, but first consider only those bits in the BitString for which the BFR-NBR is known to be down - and only then consider all the bits for whom the BFR-NBR is not down.¶

static DownBfrNbrIndices;
static DoFRRIndices;
GetFirstBitPosition(BitString)
   {
       DoFRRIndices = 1;
       return GetNextBitPosition(BitString, 0)
   }

GetNextBitPosition(BitString, Index)
   {
      if( DoFRRIndices && Index = _GetNextBitPosition(Packet->BitString & DownBfrNbrIndices, Index)) {
          return Index;
      }
      DoFRRIndices = 0;
      return _GetNextBitPosition(Packet->BitString & ~DownBfrNbrIndices, Index);
   }

Figure 12 shows how this behavior can be modelled by modifying the functions enumerating the BitIndices. DownBfrNbrIndices is a bitstring variable changed by fast executing control plane code, whenever an interface connecting to a BFR-NBR goes up or down. It includes all BitIndices of BIFT entries whose BFR-NBR is down.¶

GetNetBitPosition now first returns all Indices in the Packet->BitString with such down BFR-NBR, and afterwards those Indices whose BFR-NBR are not down.¶

In result of this change, in Example 5, when R5 is down, the BIFT entry for R10 is examined first, resulting in a packet copy with R8,R9,R10,R11 towards R4, because R5 is down, and later no additional packet copy needs to be made because the Bits for R8,R9 where already cleared by that first copy.¶

[ RFC-editor: remove the following paragraph, it is only here for convenience of reviers to relate to a prior version of the document ]¶

Note: Earlier versions of this document, such as revision 10, had called BIER-bFRR single-BIFT (with FRR) and BIER-sbFRR multiple BIFT because it was modelled as one BIFT just with primary F-BM/BFR-NBR and another one only with BF-BM/BBFR-NBR for the failure of one specific interface. Likewise, section 3.8 claimed that it would be necessary to perform two passes through this type of BIFT: this text it is not necessary to perform two passes as written there: "A first one matches the bitstring combined with BEA=1. If no further match is possible, then another pass with the remaining bitstring combined with BEA=0 is performed.". The rewrite presented above with bFRR and sbFRR replaces this with the simpler model of a single BIFT extended with BF-BM/BBFR-NBR and just uses two different ways to sequentially process the bits in the packets BitString.¶

3.5. BIFT for partitioned q-space

This section discusses how the different BIFT models presented can deal with partitioned q-space as defined in Section 2.2.2.4. The difference in behavior is between BIER-aFRR and BIER-bFRR/sbFRR. There is no difference in between bFRR and sbFRR.¶

Figure 13 shows the relevant excerpt of the R1 BIFT using the BIER-bFRR/sbFRR BIFT model. As explained in Section 2.2.2.4, when R2 fails, R1 can only delivery BIER packets for R5 and R6 through a unicast encapsulation (tunnel) destined to R11 and send to R12. Likewise, to reach R7 and R8, the BIER packet needs to be encapsulated to R13 and that unicast packet sent to R12. Because both tunneled packets have different unicast destinations, these four BFER (R5,R6,R7,R8) can not be served with a single BIER packet copy.¶

In unicast LFA terminoloy such unicast encapsulated FRR packets are called remote LFA ([RFC7490]) and the syntax shown for BBFR-NBR in Figure 13 expresses the required tunnelling accordingly.¶

Figure 14 shows a first attempt to express the same situation with the BIER-aFRR BIFT model in which there are no new BIFT fields BB-FM or BBFR-NBR. Instead, and as explained in Section 3.2, the RLFA 'adjacency becomes the value of the BFR-NBR. It indicates the directly connected BFR-NBR R2, and if the interface to that neighbor is down, then instead the packed has to be tunnel encapsulated to destination R11 or R13 and send towards BFR-NBR R12.¶

However, this BIFT does not work as expected because it can not represent the BB-FM of a bFRR BIFT. And the goal of the aFRR model is explicitly to only use non-BIER specific FRR options for the BFR-NBR field, so that hopefully even unchangeable (hardcoded) BIER forwarding code could be extended to support aFRR - because it should be possible to implement aFRR solely through pre-existing unicast FRR adjacency forwarding.¶

The reason why this BIFT will not work is that a packet to R5,R6,R7,R8 will not be processed as desired under failure of R2: As long as R2 is up, the BIFT delivers the expected result, sending one BIER packet copy to R2 with all the four bits for R5,R6,R7,R8 set. But when R2 goes down, then only one packet copy will be sent too, and that is the one derived from the BIFT entry for R5 which already includes all four bits in the bitstring because of its F-BM. Only when a packet would not have R5 or R6 set, but only R7,R8 would their BIFT entries kick in and a packet copy tunneled to R13 be sent!¶

Figure 15 shows the fixed aFRR BIFT. The F-BM between R5,R6 and R7,R8 are now split, so that a packet to R5,R6,R7,R8 under failure of R2 will receive one tunneled packet copy destined towards R11 with destinations R5,R6 and triggered by the BIFT entry for R5, and a second packet copy destined towards R13 with destinations R7,R8 and triggered by the BIFT entry for R7.¶

The downside of this approach is obviously that when R2 is up and running, then a BIER packet for R5,R6,R7,R8 will not be sent as a single packet copy towards R2, but instead as two packet copies to R2. One with the bits for R5,R6, triggered by the BIFT entry for R5, and one with the bits for R7,R8, triggered by the BIFT entry for R7.¶

The ability to use an unchanged BIFT and BIER forwarding algorithm and just use "unicast" FRR adjacencies therefore comes at the price of having to carry unnecessary packet copies when there is no FRR failure - just because there is only a single F-BM in a non-bFRR enhanced BIFT and hence the F-BM space needs to be segmented by the segmented q-spaces of the BFER. In the example topology, this duplicated amount of traffic only exists over link L1 from R1 to R2. As soon as those two packets hit R2, the one with bits for R5,R6 will be sent towards R3, and the one with the bits for R7,R8 will be sent towards R13. This mechanism never creates packet duplication on actual receivers, but it only creates less BIER packet de-duplication on transit links!¶

For fast core networks, this lower de-duplication efficiency of BIER to support FRR without e.g.: new forwarding hardware (which may be required for bFRR) may well be worth it, especially if the aggregate of BIER traffic multiplied by the number of q-space particions (e.g: 2 in this example) is a well acceptable percentage. Assume for example link L1 between R1 and R2 is 100Gbps and the total amount of multicast (BIER) traffic is 5 Gbps at most. Then this solution would waste (just) 5% (5Gps) of the bandwidth from R1 to R2 - compared to BIER-bFRR.¶

4.1. Summary of options

In "Tunnel-based BIER FRR"The most simple option to perfor¶

5.1. Definition of Forwarding Actions

A BFR-NBR is considered directly connected if it is a link-layer next-hop. Conversely, if the BFR-NBR cannot be reached directly through the link layer, it is regarded as indirectly connected.¶

The following forwarding actions are defined:¶

• Plain: The BIER packet is sent directly to a BFR-NBR via a direct link without encapsulation in a tunnel. This indicates that the packet is not forwarded through the underlying network.¶

• Tunnel: The BIER packet is encapsulated with a tunnel header and forwarded to a BFR-NBR over the routing underlay.¶

• Explicit: The packet is forwarded along an explicit path to a BFR-NBR. The specific path information must be provided. If segment routing is employed for this purpose, the segment IDs (SIDs) must be specified. Two forwarding actions of type Explicit are considered equivalent only if they utilize the same explicit path.¶

In the BIFT as outlined in [RFC8279], the forwarding actions are implicitly determined by the connectivity status of the BFR-NBR. If the BFR-NBR is directly connected, the forwarding action is Plain. If the BFR-NBR is not directly connected, the forwarding action is Tunnel.¶

5.2. Backup BIFT

The structure of the backup BIFT is given in Figure 16.¶

The columns refer to:¶

• BFR-id: the bit position of a BFER for which this row in the backup BIFT applies.¶

• BF-BM: the Backup F-BM used for forwarding, used like the primary F-BM.¶

• BBFR-NBR: the Backup BFR-NBR used for forwarding, used like the primary BFR-NBR.¶

• BFA: the Backup Forwarding Action takes values as introduced in Section 3.1 and indicates how the packet is forwarded to the BBFR-NBR.¶

• BEA: the Backup Entry Active flag indicates if the backup forwarding entry of this row is active.¶

The structure and semantics of the first three fields are identical to the entries of the primary BIFT, as defined in Figure 3 of [RFC8279], and they are used in a very similar way. The BEA indicates if the backup forwarding entry is executed. In that case, the BFA indicates the forwarding action for the packet.¶

5.3. Activating and Deactivating Backup Forwarding Entries

When a primary BFR-NBR is not reachable over the implicit primary action, a failure is observed. Then, the BEA flag of the corresponding backup forwarding entry is set.¶

If the primary BFR-NBR is directly connected, the information about the failed interface is sufficient to detect its unreachability. If the primary BFR-NBR is indirectly connected, a Bidirectional Forwarding Detection (BFD) [RFC5880] session between the BFR as PLR and the BFR-NBR may be used to monitor its reachability.¶

If the primary BFR-NBR is reachable again, the BEA flag is deactivated. This may be caused by the disappearance of the failure or by a change of the primary BFR-NBR due to a reconfiguration of the BIFT.¶

5.4. Usage of the Backup BIFT

An incoming packet is first matched against the backup BIFT. A row in the backup BIFT matches a packet if the BEA flag in the backup BIFT is set and if the BFR-id is set in the packet's bitstring. Then, the BF-BM of the matching backup forwarding entry is applied to the packet's bitstring. That means, the packet is copied and in its bitstring the bits other than those set in BF-BM are cleared before the packet is forwarded to the BBFR-NBR with the indicated BFA. Finally, the bits of the BF-BM are cleared in the bitstring of the remaining packet. In the absence of a match of the remaining packet, the normal forwarding procedure continues, i.e., forwarding based on the primary BIFT as described in [RFC8279].¶

Note: If a BFR-id matches in the primary or backup BIFT, and the transmission is not successful, the F-BM or BF-BM is still applied to the bitstring of the remaining packet.¶

5.5. Computation of the Backup F-BM

The primary F-BM of a specific BFER identifies all BFERs that share the same primary BFR-NBR. The backup F-BM for a specific BFER is computed to indicate:¶

• All BFERs that share both the primary and backup BFR-NBRs of the specific BFER, and¶

• All BFERs for which the backup BFR-NBR of the specific BFER serves as the primary BFR-NBR.¶

5.6. Alternative Representations of Backup Forwarding Entries

Alternative representations of backup forwarding entries are possible as long as the same behavior is ensured. Two other variants are introduced in the following sections.¶

5.7. Single Extended BIFT

The information of the primary BIFT and the backup BIFT may be combined in a single extended BIFT. Its structure is illustrated in Figure 17.¶

To ensure the same behavior, the BEA flag must be set like in the backup BIFT. Furthermore, two matching passes through the extended BIFT are needed. A first one matches the bitstring combined with BEA=1. If no further match is possible, then another pass with the remaining bitstring combined with BEA=0 is performed.¶

5.8. Primary BIFT and Failure-Specific Backup BIFTs

To avoid two distinct passes through a BIFT, the information of the primary BIFT and backup BIFT may be combined into a primary BIFT and multiple failure-specific BIFTs. Each failure-specific BIFT corresponds to a specific failure scenario. Failure-specific backup BIFTs are structured like normal backup BIFTs, but do not have a BEA flag as they are enabled or disabled as a whole.¶

In the absence of a failure, packets are processed using the primary BIFT. In case of a failure, packets are processed using a failure-specific BIFT that matches the occurred failure. That means, there should be failure-specific BIFTs for at least any adjacent link to protect against all single-link failures. To support multiple failures, even more failure-specific BIFTs are needed. If failure-specific BIFTs are provided for only single-link failures, the BIFT should be taken that covers the most relevant single failure.¶

6.1. Example

Figure 18 presents an example of a BIER network. In this example, BFRs are identified by the prefix "B" followed by their BFR-ids. For simplicity, each BFR also serves as a BFER, and its bit position in the bitstring corresponds to its BFR-id. The number assigned to each link represents its cost, which the routing underlay uses to compute the shortest paths.¶

In the absence of a failure, traffic for BFR-id 2 and 3 is forwarded via BFR-NBR B2 and traffic to BFR-id 4, 5, 6, and 7 is forwarded to BFR-NBR B6. If a packet with bitstring 0001100 (destinations B3 and B4) is forwarded, the row for BFR-id B3 matches first. A packet with bitstring 0000100 is sent to B2 and the bitstring of the remaining packet is also processed with F-BM 0001100, i.e., the remaining bitstring is 0001000. Then the remaining bitstring is matched again so that BFR-id B4 yields a match. A packet copy with bitstring 0001000 is sent to B6 and the application of the F-BM 1111000 to the bitstring of the remaining packet results in 0000000, which terminates the forwarding process. This BIER forwarding process avoids redundant packet copies.¶

A backup BIFT for B1 in the example of Figure 2 is given in Figure 19. It implements LFA-based FRR as a protection strategy and link protection.¶

If B1 cannot reach B2 or B6, BEA will be set to 1 in the rows for the backup BIFT for which B2 or B6 is the BFR-NBR in the primary BIFT. Thus, if B1 cannot reach B2, traffic for BFR-id 2 and 3 will be forwarded over B6 and 1111110 is applied as BF-BM. This mask also includes all the BFR-ids that have B6 as their primary BFR-NBR. Likewise, if B1 cannot reach B6, traffic for BFR-id 4, 5, 6, and 7 will be forwarded over B2 and again 1111110 is applied as BF-BM for the same reason.¶

6.2. B1's backup BIFT for LFA-based FRR with link protection

We now consider that the link B1->B2 failed and that B1 needs to forward a packet with bitstring 0001100. Therefore, the BEA is set for BFR-id 2 and 3 in the backup BIFT. If B1 needs to forward a packet with bitstring 0001100 (destinations B3 and B4), the row for BFR-id B3 in the backup BIFT matches first. Therefore, a packet with bitstring 0001100 is sent to B6 and the bitstring of the remaining packet is also processed with BF-BM 1111110 so that the remaining bitstring is 0000000, which terminates the forwarding process. That is, only a single packet copy is sent to B6.¶

8.1. Link Protection

In link protection, the backup path is designed to circumvent the failed link, i.e., the failed primary path from the PLR to the primary BFR-NBR, while still potentially including the primary BFR-NBR itself. Consequently, the backup path with link protection cannot protect against the failure of the primary BFR-NBR.¶

8.2. Node Protection

In node protection, the backup path is designed to avoid both the failed node and the link to that node, i.e., the failed primary path from the PLR to the primary BFR-NBR, including the primary BFR-NBR. Consequently, the backup path with link protection also protects against the failure of the primary BFR-NBR. If a BFER and its primary BFR-NBR are the same, only link protection is feasible for that BFER.¶

8.3. Example

In the network depicted in Figure 18, the primary path from BFR B1 to BFER B5 is B1->B6->B5. Protecting BFER B5 from a BFR-NBR B6 node failure can only be provided through the backup path B1->B2->B3->B4->B5. Link protection for BFER B5 is achieved via the backup path B1->B2->B7->B6, and additionally through the backup path B1->B2->B3->B4->B5->B6. The specific backup entries are determined by the selected protection level and backup strategy. Example BIFTs illustrating link and node protection are provided in Section 9.¶

9.1. Tunnel-Based BIER-FRR

The routing underlay may possess the capability to forward packets to their destinations even in the presence of a failure, potentially due to FRR mechanisms within the routing underlay. In such scenarios, while the primary BFR-NBR may no longer be reachable via the primary action (Direct), it could still be accessible through a backup action (Tunnel).¶

Tunnel-based BIER-FRR encapsulates BIER packets impacted by a failure within the routing underlay, thereby leveraging the routing underlay's fast restoration capabilities. As soon as connectivity in the routing underlay is reestablished, the affected BIER packets can be forwarded to their intended destinations. The appropriate backup forwarding entries in a BIFT for BIER-FRR are determined by the desired protection level.¶

9.2. LFA-based BIER-FRR

LFA-based BIER-FRR leverages alternate BFRs to deliver BIER packets to BFERs if their primary BFR-NBR is unreachable. This approach does not rely on any fast restoration or protection mechanisms in the underlying routing infrastructure. First, the prerequisites for LFA-based BIER-FRR are clarified, followed by the definition of BIER-LFAs. Subsequently, link and node protection for LFA-based BIER-FRR are discussed using a single backup BIFT.¶

10.1. Comparison of LFA-Based Protection for IP-FRR and BIER-FRR

LFAs were initially proposed for IP networks. They are straightforward in that they do not require any tunneling overhead. However, certain destinations cannot be protected against specific link failures, and even more destinations may be unprotectable against certain node failures. To improve coverage, remote LFAs (R-LFAs) were introduced, which tunnel affected traffic to another node from which the traffic can reach the destination through normal forwarding. Despite this, there may still be destinations that remain unprotected against link or node failures. To address this, topology-independent LFAs (TI-LFAs) were developed, wherein affected traffic is tunneled via an explicit path (preferably using segment routing headers) to another node from which the traffic can reach its destination through standard IP forwarding. With TI-LFAs, all destinations can be protected against any failures as long as connectivity exists.¶

LFA-based BIER-FRR adopts the principles of LFAs but differs from IP-FRR in that the LFA target node, i.e., the next-hop on the BIER layer to which traffic is diverted, must be a BFR. If an IP-LFA target is a BFR, it can be utilized as a BIER-LFA; otherwise, it cannot serve as a BIER-LFA. Consequently, if only a subset of nodes in the underlay are BFRs, the BIER-LFAs will differ substantially from IP-LFAs. Furthermore, this makes it more challenging to find normal BIER-LFAs which do not require tunneling. As a result, LFA-based BIER-FRR is likely to require more remote BIER-LFAs and TI-BIER-LFAs than IP-FRR under such conditions.¶

10.2. Advantages and Disadvantages of Tunnel-Based BIER-FRR

10.3. Advantages and Disadvantages of LFA-Based BIER-FRR

A.1. BIER-in-BIER encapsulation

Figure 26 is again the example shown in Figure 4. One option not discussed in before - because it can reasonably not be made to work - is to attempt using BIER-in-BIER encapsulation to improve over the solution described.¶

One way how one could attempt to avoid having to send out two copies from R1 under the failure of R2, one towards R11 to then reach R5, R6 and one towards R13 to then reach R7, R8 is to consider encapsulating the packet into a new BIER header which for example has as destinations (BFER) R11 and R13. When R11 and R13 respectively receive this packet, they decapsulate it, encounter the original BIER packet (that was FRR redirected by R1), and continue to forward it to it's ultimate destinations.¶

Unfortunately, this topology also shows how this would fail. When R11 would process the original BIER packet and encounter the bits for either R7 and.or R8, then it would send a copy back to R12 to reach R7, R8. That copy would again reach R1, and in result in another FRR'ed copy of the same packet. This duplication would only stop due to TTL expiry.¶

Arguably, if the BIER encapsulation was choosen not to send copies towards R11, R13, but instead R12, R4, then this looping would not happen because the copy for R7, R8 from R12 would instead be sent towards R3, which would send it towards R2 which assumably has failed and hence the packet copy from R3 would be dropped.¶

However, in reality FRR would not only be set up on R1 towards R2, but equally on R3 and R7, so both of them would equally create FRR packets when they recognize R2 to be down.¶

B.1. rev 13 -

Wrote new chapter 3 BIFT/forwarding to specify a simplified set of forwarding/BIFT options for FRR. They are explained on one simple topology example that shows how they do create different outputs of packets in the FRR case. These differences are what justifies the need to specify or in future standardize the models - operators need to be able to verify behavior of router (with BIER/FRR) against specified behavior to see if it works correctly, and they need to be able to plan capacity based on the expectation of how much BIER traffic will flow with FRR.¶

Beyond section 3 is still old text, need to negotiate with other authors how much of that is still useful.¶

TBD: algorithms to calculate FRR in control plane.¶

B.2. rev 12 -

Intermediate version. Added primarily the Overview Chapter to better introduce the concepts and benefits of BIER-FRR to readers (customers et all) only aware of unicast FRR, and to better explain unicast FRR concepts (p, q space) to readers primarily aware of BIER.¶

Changes / optimizations in further parts of the document yet.¶

B.3. rev 11 - sent back from IESG to WG

Triage of IESG review feedback. Fixed the following core / simple feedback. See TBD section below for the missing IESG and directorate review feedback that will need to be folded into the next rev's.¶

Brought document into kramdown format for easier editing.¶

Rewrote abstract to answer Roman Danyliw / Éric Vyncke / Brian Haberman questions about scope (framework) and intended status (informational) of document.¶

Changed set of authors to meeth 5-authors max requirements. Changed authors to contributors.¶

Removed RFC2119 boilerplate because as a framework, this document does not use RFC2119 language (Mike Bishop).¶

Resolved Eric Vyncke Abstract text convern (removed). But see TBD for more work on refining text required.¶

Resolved expanding LFA on first use.¶

Ketan: Please remove extra "." I saw a few other similar instances in the document.¶

Ketan: minor: perhaps s/reconvergence/control plane reconvergence .¶

Ketan: fixed "persistent failure" text.¶

Ketan: In the following ? ... perhaps "In this subsection," ?¶

B.4. Resolved IESG discuss / comments before rev 11.

Added text for BFD referring to RFC5880 (prior no use of RFC5880 reference).¶

EVyncke: s/without encapsulation in a tunnel header/without encapsulation in a tunnel/¶

EVyncke: s/link layer technology/link-layer technology/¶

B.5. TBD

Consider adding text about optimizations introducing forwarding plane behavior (e.g.: when processing multiple bits per BIFT entry. Need to find example showing this).¶

Fold in RTGDIR feedback (eckert).¶

Fold in unanswered questions from INTDIR review (Haberman): https://datatracker.ietf.org/doc/review-ietf-bier-frr-08-intdir-telechat-haberman-2025-06-03/)¶

Section 6.1: Add text about PMTU when using tunnels (Evyncke DISCUSS). Although: RFC7490 which explicitly require stunnels also does not address tunnels MTU issues. Maybe attempt to declare MTU problem out of scope given how we're "just" doing something similar for BIER that several unicast RFCs are doing - without addressing MTU.¶

Check/remove unused references. Add text explaining benefits of reading reference "Performance Comparison of Resilience Mechanisms for Stateless Multicast Using BIER" (aka: which pieces relevant to this draft does this research paper cover).¶

Add text about egress protection (Aka: node protection against BFER failure), reference I-D.chen-bier-egress-protect (Roman Danilyv).¶

EVyncke: I fail to see the logical link between Typically, BIER packets are forwarded without an outer IP header. and the consequence if a link or node failure occurs, the corresponding BFR Neighbor (BFR-NBR) becomes unreachable. Strongly suggest adding some explanations. Answer: linkage is that BIER can not automatically use IP FRR but has to deal with unreachability events itself. But even if BIER was using per-hop IP/MPLS encap to rely on IP/MPLS FRR, then the result would not be as good as "direct" BIER-FRR. Text rewrite requires some restructuring.¶

EVyncke: Should a reference be provide for SR in If segment routing is employed ?¶

Evyncke: The last paragraph does not mention the 'explicit' forwarding action, is it on purpose ? If so, the read will welcome an explanation.¶

Ketan: major: Please provide a reference or explanation of "normal BIER-LFAs". Did you mean RFC5286? Same goes for the other types - please provide references. TBD because text needs more structured rewrite of aligning the BIER behavior with the pre-defined unicast FRR terminology / cases.¶

Ketan: Is that IP-TI-LFA ? Same Q for TI-BIER-LFA. Need more structured rewrite of text...¶

Ketan: Isn't that 100% theoretical? Practically, there are limits of platform and implementations. Also, all routers should be BFRs. Answer: No, should be as practically applicable as unicast TI-LFA is. There may be othrer platform limitations for BIER-FRR though.¶

DebCooley: The word 'tunnel' is used many times in this draft. There is no definition of what is meant by tunnel(s), I have to assume that they are not for security purposes. If they are specific types of tunnels, e.g. MPLS or other security tunnel options (IPsec), then it would be nice to have that defined. Yes: Need to define "tunnel" for the purpose of this ocument as an encapsulation of BIER packets into some unicast header that allows forwarding of the packet to a remote BFR. On the other hand, RFC like RFC7490 (RLFA in unicast) uses "tunnel" without explaininf/defining it.¶

Ketan: References to respective RFCs related to different types of LFA/FRR unicast mechanisms would be helpful in this section as well. Yes!¶

All of Mohammeds IESG review (sorry, ran out of time).¶