]> Futurewei

hchen.ietf@gmail.com

Futurewei

michael.mcbride@futurewei.com

University of Tuebingen

steffen.lindner@uni-tuebingen.de

University of Tuebingen

menth@uni-tuebingen.de

Futurewei

tte@cs.fau.de

This document provides a framework for the development of Fast Reroute (FRR) mechanisms for Bit Index Explicit Replication forwarding (BIER-FRR). BIER-FRR can provide protection against link or BFR failure by invoking locally pre-determined repair paths that can react in the same time-scales as (unicast) FRR for MPLS or IP networks - "sub 50msec", and without the creation of additional per-path or per-flow state coordinated across multiple routers/LSR. BIER-FRR can be implemed locally within a router/LSR with minimal interoperability requirements against other router/LSR. It can therefore easily be introduced incrementally or selectively where needed. BIER-FRR implementing nodes only need to understand the routing topology of the network for calculation of repair paths and know what type of unicast encapsulation can be used to send ("tunnel") BIER packets to remote BFR. This document proposes and discusses different options for BIER forwardng (BIFT) extensions to support BIER-FRR. These are exemplary and non-normative. This document does not specify any standards or experiments but aims to support such efforts.

Terminology This document uses the following definitions: BIER: Bit Index Explicit Replication BIER-FRR: Bit Index Explicit Replication Fast ReRoute BFR: Bit-Forwarding Router BFR-NBR: Bit-Forwarding Neighbor BFIR: Bit-Forwarding Ingress Router BFER: Bit-Forwarding Egress Router BIFT: Bit Index Forwarding Table F-BM: Forwarding Bit Mask PLR: Point of Local Repair LFA: Loop Free Alternate BF-BM: Backup F-BM BBFR-NBR: Backup BFR-NBR BFA: Backup Forwarding Action BEA: Backup Entry Active

Overview BIER-FRR describes how IP FRR style sub-50 msec protection can be done for BIER. The BIER-FRR mechanisms described in this document adhere to a primary/backup path model, also known as 1:1 protection where traffic is forwarded either over a primary path or over a backup path. It is in contrast to a 1+1 protection model, where traffic is duplicated across both primary and backup paths. That 1+1 principle has been described by Multicast-only Fast Reroute (MoFRR) and was explored for BIER in . This memo is informational because it is a technology primer explaining the benefits of and mechanisms for Fast ReRoute (FRR) with Bit Inexed Explicit Replication (BIER) stateless multicast forwarding. This document is not a standards track document because o Most if not all mechanisms possible can be implemented solely on single routers supporting BIER without the same or "interoperable" new mechanism to be supported by other routers supporting BIER. o At this point in time, it is unclear which of the advanced mechanisms presented are most feasible for implementation adoption in different type of routers supporting BIER, because the feasibility of implemeting them depend on the specifiec abilities of the routers forwarding plane.

Benefits BIER is a novel method that allows to simplify and scale the deployments of multicast services significantly over widely deployed technologies like for IP networks including SRv6 networks or 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 achieves the same networks for unicast traffic. Stateful multicast mechanisms including and can not support FRR directly. Instead, they must be combined with prior mechanisms to achieve link-protection (such as with 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.

BIER versus IP multicast BIER is a novel method for so-called "stateless" forwarding and replication of traffic, especially IP multicast, across networks such as Service Provider network. BIER is intended to replace prior, so-called "stateful" methods of IP multicast, such as the predominantly deployed in these networks. In IP (unicast), variations in user traffic across such a Service Provider network do only impact capacity utilization of the network (links and nodes), but not the control-plane activity and forwarding plane state scalability: IGP and BGP routing protocol operations and scalability and derived forwarding plane scalability and change performance. Only changes in the network topology through failures, recovery and network expansion cause the need for high-performance control-plane activity and/or increased scale requirements. This makes IP unicast Service Provider network designs arguably very easily scalable to arbitrary levels of throughput, a core requirement for successful Service Provider network deployments. In stateful IP multicast, this is not the case. Every individual new IP multicast application, with new senders and/or receivers can create new control-plane state (from e.g.: PIM-SM) hop-by-hop across such a Service Provider network. Every failure or recovery of links or nodes in the network require control-plane and forwarding-plane re-convergence that needs to be able to scale not with the total size of the network (unicast routing table), but with the total number of IP multicast applications. Denial of Service attacks in IP multicast are equally not limited to attempts of overloading network bandwidth, but can more easily attempt to overload this control-plane and forwarding-plane state through the creation of new IP multicast application state. Because this does not even need for the attackers to have significant bandwidth available, this attack is a lot easier to achieve. BIER resolves these issues by eliminating the per-IP-multicast application state across Service Provider networks by utilizing fundamentally very much the same packet forwarding paradigm as IP (unicast). The packet simply contains a list of destinations in it's packet header (encoded very efficiently as a bitstring), and on every hop the packet is replicated and forwarded to all the next-hop routers towards one or more of those destinations. No IP-multicast group state is required for this forwarding.

FRR for BIER versus IP/MPLS unicast and multicast In IP-FRR, which is also applicable to FRR for SR-MPLS (and hence MPLS networks), unicast packets are forwarded by every router/LSR (Label Switched Router) based In IP (IPv4 and IPv6), packets are forwarded hop-by-hop in routers based on the destination address of the packet. for each destination (prefix) the forwarding entry indicates a next-hop which may be an outgoing interface or an outgoing intercace with a particular next-hop-neighbor if the outgoing interface is a multi-access subnet (like ethernet with multicast routers connected to it). IP-FRR amends the per-packet forwarding with a check whether the outgoing interface or the next-hop-neighbor are failed. If so, then the packet is instead forwarded to a so-called FRR adjacency, which is primarily a different interface/next-hop-neighbor, but can also involve an additional 'steering' header, such as from SR-MPLS or . These FRR adjacencies are pre-calculated by the routing control plane. Note too, that these IP-FRR mechanisms are not limited to IP networks including SRv6 networks, but they are equally applicable to SR-MPLS networks. In BIER-FRR, exactly the same principles of IP-FRR can be used, except that when a BIER packet is processed by the forwarding plane, a forwarding decision needs to be taken not only once (as in unicast), but once for every bit (destination) in the bitstring. For each bit, an interface/next-hop-neighbor is determined and a copy of the packet is sent to it. Unless such a copy was already made for a prior examined bit in the packets bitstring, hence avoiding more than one copy of the packet to each interface/next-hop-neighbor. Each packet will also receive a modified version of the bitstring which indicates the subset of bits in the received packets bitstring which are reachable across this same interface/next-hop-neighbor. Beside being able to apply all the same mechanisms to BIER-FRR as available in IP-FRR, BIER-FRR specifically maintains the benefit of the most efficient hop-by-hop replication, even when a packet has to be put onto a BIER-FRR adjacency.

pre-existing unicast LFA algorithms for LFA from R1 to R6 in case of R2 failure would for example calculate that it is sufficient to encapsulate a packet up to R10 but towards R8, that encapsulation endpoint would need to be R11 because R10 would send back packets to R8 to R9 because that is its shorted path (before reconvernce). Consider some multicast packets from R0 would need to be received by a subset of (R6,R7,R8). They would be forwarded from R0 to R1, by R1 to R2, and from R2 to R3, R4, R5 to then reach R6, R7, R8. Assume one multicast group, G1 would only need to go to R6. R2 would then have multicast forwarding state G1 -> (R3) to copy the packet only to R3. Another group G2 would need to go to R6, R7, R8. R2 would then have G2 -> (R3, R4, R5) meaning it would replicate packets to G1 to R3, R4 and R5. Assumme R2 fails. FRR in R1 would recognize this as a failure of the link to R2 and be configured to assume this indicates failure of R2 and hence pre-established R2 node-protection FRR would kich in. Instead of sending a packet to R2, R1 it would send the packet onto the FRR packup path. With existing stateful multicast, FRR in R1 would have needed to pre-calculate and install three unicast backup path ("tunnels"). R1-...->R3, R1-...->R4 and R1-...->R5. R1 would then have to send three copies of each multicast packet, one into each backup path. If this was a packet for G1, then two of these copies would be in wain and be discarded by R4 and R5. If a stateful multicast FRR solution would want to avoid such unnecessary excess traffic, it would need to install per group FRR state - a separate state for G1 and G2. In real networks there are not just 2 groups but thousands (#G). In the picture, R1 only has one outgoing interface to which to replicate. In a real network, it would have on average N outgoing interfaces/next-hops and this type of traffic optimized FRR for stateful multicast would create #G*N additional states on each hop. In addition, new protocol mechanisms to signal all this information would need to be developed, because today, R1 would not know which group would need to go to which subset of R3,R4,R5. Such protocol mechanisms where never developed and hence this type of stateful FRR for "node protection" (in this case for the failure of R2) is just theoretical. With BIER-FRR, the solution becomes extremely simple for this example. The BIER-FRR control plane in R1 can calculate that the FRR adjacency for the case of R2 failing for all three possible destinations R6, R7, R8 can be R11. When R1 recognizes failure of (link to) R2, it would send the BIER packet with exactly the same bits encapsulated towards R11 (via R9, R10) and there normal BIER forwarding proceeds. According to the subset of bits for R6, R7, R8 set in the bitstring, R3,R4,R5 would make according copies. Like in FRR for unicast, it does not matter to BIER that the packet did arrive from R10 as opposed to R2, it is only revelant what destinations it has (in its bitstring). R2 could not simply send the packt to R9, because it is not aware of R2 having failed, so its routing table would send packet packets for R6,R7,R8 towards R1 because that is the shortest path from R9 to R6,R7,R8. Likewise, R10 too would still send back packets towards R8 to R1. Only for R11 are paths not across the failed R2 the shortest path towards R6,R7,R8. Note that the forwarding described for BIER-FRR here is LFA-based BIER-FRR in the terminology introduced later in this document.

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.

Tunnel-based BIER-FRR In this approach, a BIER forwarding entry to a BFR-NBR is replaced by an (IP)-FRR protected adjacency which encapsulates the BIER packet into a unicast packet towards that BFR-NBR. This is exactly what classicial (non IP) FRR in MPLS was and is doing with RSVP-TE backup tunnels. Hence the name tunnel-based. For example, assuming the topology of and R1 as the BFR where this form of FRR is to be installed. Usually a BIER forwarding entry towards R2 is simply an L2 adjacency for BIER packets. Instead, that L2 adjacency towards R2 is set to be a unicast encapsulation (IPv4, IPv6 or SR-MPLS) with a unicast IPv4/IPv6 destination of R2. In the case of SR-MPLS, the actual encapsulation will have an MPLS SID for the IPv4 and/or IPv6 address of R2. Absent a failure of link L1, this change means simply an "unnecessary" encapsulation of BIER packets from R1 to R2 and decapsulation there. If instead, the link L1 fails, the BIER packet on R1 will get encapsulated into the unicast packet, and once it is to be forwarded as unicast, the unicast forwarding will determine that the link L1 has failed and will hence forward the packet on the pre-calculated unicast FRR adjacency towards R2. In the topology this means that so-called TI-LFA (Topology Independent LFA) has to be used which can calculate that packets towards R2 (in case of L1 link failures) need to be encapsulated with a destination address of R11 - because sending the FRR packet only towards R9 or R10 would have it be returned towards R1. In other topologies, simple (non TI) LFA may suffice. In those cases, the FRR adjacency would simply be to send the unicast packet to another next-hop without additional encapsulation.

Limitations Tunnel-based BIER-FRR is only applicable to link-protection but not node-protection. This is because Tunnel-based BIER-FRR is based on only having to replace BIER (L2) adjacencies with already existing FRR protected unicast adjacencies. Tunnel-based BIER-FRR is not applicable to node-protection because a failure of the next-hop means that some other router in the network would need to replace the replications of BIER packet that this failed router could have done, and there is no unicast FRR function that would do this. The traffic efficiency of Tunnel-based BIER-FRR is typically lower than that of LFA-based BIER-FRR because the traffic needs to be tunneled towards the BIER-NH and from there back as a regular BIER packet. In the topology of a Tunnel-based BIER-FRR packet from R1 to R6 would go R1-R9-R10-R11-R11-R12-R3-R2(decap)-R3-R6, whereas as described in before, LFA-based would have it simply go R1-R9-R10-R11-R11-R12-R3-R6 (not via R2). Because Tunnel-based BIER-FRR requires FRR protected adjacencies to a next-hop, unicast FRR needs to be configured to not only provide node-protection adjacencies but also link-protection adjacencies to all direct neighbors that are also BIER neighbors. This should be standard unicast FRR deployment though when node-protection is used.

Benefits Tunnel-based BIER-FRR is least demanding to the BIER forwarding plane and should be most easy to implement on any BFR already supporting unicast LFA. No changes to the BIER forwarding tables (BIFT) are required other than replacing the BFR-NBR entries. For both unicast and BIER, Tunnel-based FRR is logically something that can happen at the link-layer, not impacting the forwarding table, and hence not requiring to scale with the size of the forwarding table. Instead of sending a packet to a neighbor in a connected subnet, FRR protection adds a check whether the interface to the subnet is up and/or the neighbor is alive, and if not, then packet is instead redirected to another interface (or neighbor on the same interface) with an additional encapsulation. The interoperability requirement for Tunnel-based is solely that the tailends of pre-calculated unicast FRR adjacencies are also BFR and will accept to forward unicast FRR encapsulated BIER packets as BIER again after decapsulation. When the total amount of multicast/BIER traffic is insignificant compared to the overall bandwidth in the network, the traffic inefficiencies of Tunnel-based BIER-FRR may be irrelevant, but the inability to provide node-protection may be insufficient. Tunnel-based BIER-FRR does not necessarily have to be built from (IP)-LFA based unicast adjacencies. It can equally be built from RSVP-TE tunnels with FRR protection (or any other unicast FRR protected tunnels), which may be attractive if those already exist in the network.

LFA-based BIER-FRR In LFA-based BIER-FRR as in (unicast) IP FRR, the goal is to directly get packets in the failure situation as directly as possible to the ultimate destinations insted of back to the next-hop router as in Tunnel-Mode. The mechanisms are exactly the same as in unicast IP FRR, specifically that it requires to establish for every destination in the unicast or BIER forwarding table (BIFT) new "FRR protected" adjacencies", and hence it requires additional forwarding resources in the order of forwarding table entries. These can often be optimized, but it does cost overall more forwarding plane resources than Tunnel-based BIER-FRR. BIER-FRR will often be able to re-use pre-existing (unicast) IP FRR adjcancies in the BIER forwarding table (BIFT), but there are some optimizations and differences to observe. These are described here.

Principles of (unicast) LFA The principles of unicast LFA are to determine a path from the node determining an adjacent link or node failure towards some desting assuming that the intermediate hops on this alternative path still have the routing tables in which there is no failed link or node. The problem with this principle is that nodes along the best alternative path would not send packets along the intended path but back to where they come from because without a failure, that could be the best path for them. Using the example of , and examining the case where R1 tries to calculate unicast link-protection FRR for the failure of link L1. It calculates for each of the destinations of interest, R6, R7 and R8 the shortest path. Each of these path goes along

LFA characterizes routers along an FRR path by whether they are part of the so-called P-space and/or Q-space . The p)re-converge space are all routers that can be reached from the router of interest (R1) in the pre-convergence routing table without going through the failed link (or node). For example from R1 under failure of L1 or R2, the routers R9, R10, R11, R12 and R13 are in p-space. R14 is not in p-space anymore because assuming all links have equal cost, the path from R9 to R14 is ECMP through either R1 and the failed link/node or R10. And R1 can not know which route R9 is using. So packets from R1 to R14 via R9 might be returned by R9. And R15 is most easily not in p-space anymore, because R9 would be guaranteed to send packets from R1 towards R15 back to R1. q-space is the reverse p-space (as q is typographically a reverse p), indicating whether a router can reach the ultimate destination without going through the failed link/node in the pre-converged routing tables. R13 is in the q-space for R8, whereas R12 is not. It has ECMP paths via R13 and R11, and the path via R11 would go via the failed link/node (L1/R2). However, R12 is in q-space for R6 and R7 though. The FRR logic is now simply that if packets can not be sent directly to an alternative next-hop without encapsulation, then they need to be encapsulated and sent to a router that is both in p-space and q-space for the final destination. Because R9 is not in q-space for any of the destinations of interest in BIER, directly sending packets to R9 does not work - whether link failure of L1 is assumed, or node failure of R2. Instead, R1 would create for R6 an FRR adjacency encapsulating the packet with an appropriate unicast encapsulation destined to R12 or R13 and make R9 the next-hop for this encapsulated packet. Likewise for R7. For R8, it would need to use R13 as the encapsulation destination. Most likely R1 would pick R12 for R6 and R7 because the path with encapsulation is typically choosen to be as short as possible but with most often insignificant differences.

Adjustments for BIER-FRR If the same logic as for unicast is choosen for BIER-FRR, it does make a significant difference whether R12 or R13 are picked as FRR for R6,R7 or if R13 is picked. For BIER, the same FRR adjacency "encapsualte towards R13" would mean that a BIER packet destined to R6 and R8 could be sent once across that FRR adjcency. If instead R6,R7 had the "encapsulate towards R12" FRR adjacency, and R8 "encapsulate towards R13", then BIER would need to send two copies of that BIER packet to R6,R8: once encapsulated for R6 towards R12 and once encapsulated for R8 towards R13. In this case, if L1 or R2 are failling, R1 would need to send two copies of the same packet instead of one if R13 was choosen as the pq-router for R6, R7 and R8. So, while the principle of unicast FRR holds true, BIER makes it more beneficial to choose longer encapsulated paths to minimize unnecessary replications. On the other hand (not shown by example topology), longer encapsulation paths may also result in longer paths from the point of decapsulation, and there may be a more complex weighting of multiple copies across the same encapsulated path versus such longer paths after the decapsulation.

Topology Independent FRR A simple encapsulation towards a router in pq-space may not suffice. This is the same for BIER-FRR as it is for unicast FRR.

Consider in that a link between R10 and R13 has a significantly higher cost than the other links in the topology. In result, R10 is in p-space, R13 in q-space and hence there is no single router in pq-space that R1 could encapsulate packets to to reach R6, R6, R8 under failure of L1 or R2. If R1 would want to send packets to ANY node in the topology across R10 under failure of L1 or R2, R10 would simply send them back because of the high cost of L2. To get packets across L2, a steering encapsulation is required that does ignore the actual IGP routing table. For example with SR-MPLS or SRv6 this could be a two-hop SID list, once to R10 and then to an adjacency-SID for R13. An adjacency SIP would only be possible to interpret by R10 and indicate to R10 to forward the packet to the interface of R13 connecting to R10. This type of FRR solutions are documented in . There are no additional considerations for BIER-FRR.

Partitioned q-space Even though the big advantage of BIER-FRR with node protection is that it allows most often and as shown in the prior example to send out just one copy of a packet to an FRR adjacency instead of to the primary adjacency, there are also cases that more than one copy need to be sent. This is always true in BIER-FRR node protection, when a BIER packet though the primary adjacency would have to reach multiple destinations (BFER) and the q-spaces for those destinations are non-overlapping (partitioned). In , R1 is the PLR and R2 is the node assumed to fail. R1 would have a BIFT in which R5, R6, R7, R8 are reachable via R2, but in case of a node failure of R2, there is no single node which is in q-space for all of R5, R6, R7, R8 (shown as p5, p6, p7, p8). R12 for example is only in p-space for R1 but not in q-space for any destination because it would go via R1 to reach any of R5, R6, R7, R8.

In result, R1 does need to create an FRR adjacencies for R5 and R6 towards R11 and one for R7 and R8 towards R13. If then a packet comes towards all of R5, R6, R7, R8, R1 will create one copy towards R11 for R5 and R6, and another copy towards R13 for R7 and R8. This creates double the amount of originally received traffic from R12 back towards R12, but from there on, it again has only one copy on each link as opposed to any non-BIER FRR mechanism which would still carry two copies for example one for R5 and another for R6. See for discussions of non-working enhancements.

BIFT forwarding for FRR This chapter describes how BIER-FRR forwarding can be modelled for the BIER forwarding plane. It starts by refreshing the BIER forwarding table behavor to then introduce three models for how FRR can be added, and finishes with the complex example for how to handle partitioned q-space in them.

Reference Example with BIER forwarding table (BIFT) , 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. 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 .

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 through the standard BIER forwarding code as shown in , copied from , 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.

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 .

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

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

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 .

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 . 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 , the forwarding code for BIER with bFRR is shown in , the four additional lines of code compared to 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.

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 .

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.

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

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.

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

shows the relevant excerpt of the R1 BIFT using the BIER-bFRR/sbFRR BIFT model. As explained in , 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 () and the syntax shown for BBFR-NBR in expresses the required tunnelling accordingly.

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

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.

Old text follows

Summary of options In "Tunnel-based BIER FRR"The most simple option to perfor

Definition of BIER-FRR BIER-FRR proposes a backup BIFT that comprises backup forwarding entries. They are executed before the primary forwarding entries in the normal BIFT which is also denoted primary BIFT in this context. In this subsection, forwarding actions are defined and the structure of the backup BIFT is introduced. Then activation and deactivation of backup forwarding entries as well as the derivation of the backup F-BM (BF-BM) are explained.

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

Backup BIFT The structure of the backup BIFT is given in .

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

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

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

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.

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.

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 .

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.

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.

Illustration and the Need for Prioritized Backup Forwarding Entries In this section, BIER-FRR is illustrated using a small example. It is pointed out that unnecessary redundant packets may occur if primary forwarding entries are erroneously applied before backup forwarding entries. Therefore, it is important that the backup BIFT is applied before the primary BIFT.

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

B2 is 2 B2 --------- B7 | cost of link B3->B4 is 4 | | cost of other links is 1 1 | | | 4 | B3 ------------------------- B4 ]]>

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

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.

Prioritization of Backup Forwarding Entries over Primary Forwarding Entries BIER-FRR defines that the backup BIFT is applied before the primary BIFT. The reason for that is twofold. First, applying the primary BIFT first may erase the forwarding information for BFERs whos primary BFR-NBR is unreachable. Second, if that can be fixed, redundant packets can occur if the primary BIFT is applied before the backup BIFT. These issues are demonstrated in the above example when the link B1->B2 has failed and B1 applies the primary BIFT before the backup BIFT when forwarding a packet with bitstring 0011000 (B3 and B4 as destinations). We first assume that B1 just ignores the failed interface when forwarding the packet with the primary BIFT but processes the bitstring of remaining packet like if the transmission was successful. That means, when BFR-id 3 matches first in the primary BIFT, no packet is sent to B2, but the bits in the bitstring are still cleared, leading to a remaining bitstring of 0001000. Another pass through the primary BIFT forwards a packet copy to B6 and clears the remaining bitstring to 0000000, which terminates the forwarding process. However, no packet will reach B3 as the bitstring information was lost during the unsuccessful transmission. We now assume a feature that saves the bitstring information when the transmission to a specific BFR-id was not successful. This can be done by AND-ing the remaining bitstring and the F-BM and OR-ing the result with a remaining backup bitstring which was initially zero. Only then the bits of the F-BM are cleared from the remaining bitstring. When B1 is to forward a packet with bitstring 0001100, the first match in the primary BIFT is for BFR-id 3. As the transmission is not successful, 00000100 is saved in the remaining backup bitstring and the remaining bitstring is 0001000. Therefore, a second match in the primary BIFT is for BFR-id 4, which sends a packet copy with bitstring 0001000 to B6. Then, the remaining backup bitstring is processed with the backup BIFT. As there is a match for BFR-id 3, another packet is sent to B6, now with bitstring 0000100. This can be considered redundant. Below the line, it is important to first process backup forwarding entries before backup forwarding entries. This avoids additions to the forwarding process with the primary BIFT and avoids redundant packets.

Protection Levels Both link protection and node protection may be supported. Link protection is designed to safeguard against the failure of an adjacent link, whereas node protection addresses the failure of a neighboring node and the associated path leading to that node. The relevance of link or node protection depends on the specific service being supported. Additionally, both protection levels can be combined with any of the backup strategies outlined in .

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.

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.

Example In the network depicted in , 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 .

Backup Strategies Backup strategies determine the selection of backup forwarding entries, influencing both the choice of the backup BFR-NBR and the backup forwarding action, and consequently, the backup path. The following sections present tunnel-based BIER-FRR and LFA-based BIER-FRR as potential strategies. Both can be implemented with BIER-FRR presented in Section 3.

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.

Tunnel-Based BIER-FRR with Link Protection In the context of link protection, the backup BFR-NBRs are identical to the primary BFR-NBRs. If a primary BFR-NBR is directly connected to the BFR acting as the Point of Local Repair (PLR), the corresponding backup forwarding action is Tunnel. Consequently, BIER packets affected by a failure are tunneled through the routing underlay to their BFR-NBR, rather than being directly sent as pure BIER packets. If the primary BFR-NBR is not directly connected to the BFR as a PLR (i.e., the implicit primary action is Tunnel), the corresponding backup action is also Tunnel. The backup F-BMs are identical to the primary F-BMs, which is consistent with the computation of backup F-BMs described in .

B2 | +------+----------+--------+-----------+---+-----------------+ | 3 | 0000110 | B2 | Tunnel | | Link B1->B2 | +------+----------+--------+-----------+---+-----------------+ | 4 | 1111000 | B6 | Tunnel | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ | 5 | 1111000 | B6 | Tunnel | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ | 6 | 1111000 | B6 | Tunnel | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ | 7 | 1111000 | B6 | Tunnel | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ ]]>

illustrates B1's backup BIFT for tunnel-based BIER-FRR with link protection in the BIER network example depicted in . The backup BFR-NBRs and backup F-BMs in this backup BIFT correspond to the primary BFR-NBRs and primary F-BMs in the primary BIFT. However, the backup actions in this backup BIFT are Tunnel, while the primary forwarding actions in the primary BIFT are Direct (which are not explicitly shown but are implicit). When B1, acting as the PLR, detects a failure of its link to B6, a BIER packet with the bitstring 0100000 destined for B6 is tunneled by B1 through the routing underlay towards B6. The specific path of the backup tunnel depends on the routing underlay and could be B1->B2->B7->B6 or B1->B2->B3->B4->B5->B6. If a BIER packet is destined for {B2, B5, B7}, an encapsulated packet copy is first forwarded via link B1->B2 to backup BFR-NBR B6 using the backup forwarding action Tunnel to deliver packet copies to BFERs B5 and B7. Subsequently, a non-encapsulated packet copy is forwarded via link B1->B2 to BFR-NBR B2 using the primary forwarding action Direct to deliver a packet copy to BFER B2. Therefore, with tunnel-based BIER-FRR, and link protection, a single redundant packet copy may occur in the event of a failure because an encapsulated and a non-encapsulated packet copy are forwarded over the same link. This redundancy occurs even though BIER packets affected by failures are forwarded before those unaffected by failures. The redundant packet is rather caused by the fact that two packet copies are sent over the link with different next-hops on the BIER layer, namely B2 and B6. A BIER packet with the bitstring 1000000 destined for B7 is forwarded along the backup path B1->B2->B7->B6->B7, as it is first delivered to the backup BFR-NBR B6. Consequently, the backup path may be unnecessarily long. This phenomenon is similar to the facility backup method described in which employs paths analogous to those in tunnel-based BIER-FRR.

Tunnel-Based BIER-FRR with Node Protection To determine the backup forwarding entries for node protection, two cases need to be distinguished. If the BFER is the same as its primary BFR-NBR, node protection is not feasible for that BFER. Therefore, link protection is applied, meaning the backup BFR-NBR is set to the primary BFR-NBR. If the BFER is different from its primary BFR-NBR, the backup BFR-NBR is set to the primary BFR-NBR's primary BFR-NBR for that BFER, making the backup BFR-NBR a next-next-hop BFR. In both cases, the backup forwarding action is Tunnel. In the first case, the backup F-BM is set to all zeros with the bit for the BFER to be protected enabled. In the second case, the backup F-BM is computed as described in .

B2 | +------+----------+--------+----------+---+-----------------+ | 3 | 0000100 | B3 | Tunnel | | BFR-NBR B2 | +------+----------+--------+----------+---+-----------------+ | 4 | 0011000 | B5 | Tunnel | | BFR-NBR B6 | +------+----------+--------+----------+---+-----------------+ | 5 | 0011000 | B5 | Tunnel | | BFR-NBR B6 | +------+----------+--------+----------+---+-----------------+ | 6 | 0100000 | B6 | Tunnel | | Link B1->B6 | +------+----------+--------+----------+---+-----------------+ | 7 | 1000000 | B7 | Tunnel | | BFR-NBR B6 | +------+----------+--------+----------+---+-----------------+ ]]>

illustrates B1's backup BIFT for tunnel-based BIER-FRR with node protection in the BIER network example provided in . BFERs B2 and B6 are direct neighbors of B1. To protect them, only link protection is applied, as B1's primary BFR-NBRs for these nodes are the nodes themselves. As described above, only the bit for B2 is set in the backup F-BM of B2, and similarly for B6. For BFER B5, the backup BFR-NBR is B5, as it is B1's next-next-hop BFR towards B5. Similarly, for BFER B7, the backup BFR-NBR is B7. When B1, acting as the PLR, detects the failure of its BFR-NBR B6, a BIER packet with bitstring 1010010 destined for {B2, B5, B7} is processed as follows: an encapsulated copy of the packet is sent via tunnel B1->B2->B3->B4->B5, another encapsulated copy is sent via tunnel B1-B2-B7, and a non-encapsulated copy is sent via link B1->B2. In this example, two redundant packets are sent over link B1->B2. Therefore, node protection may result in more redundant packet copies than link protection. Caveat: If the routing underlay does not support node protection, tunnel-based BIER-FRR will similarly be unable to provide node protection. This limitation is illustrated in the following example. In the network depicted in , the underlay offers only link protection. If BFR-NBR B6 fails and B1 must forward a packet to B5, according to the backup BIFT in the packet is tunneled towards B5. The underlay may route the packet along the path B1->B2->B7->B6->B5 due to FRR with link protection. However, since B6 is also unreachable from B7, the packet is returned to B2, resulting in a loop between B2 and B7.

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.

Relation of BIER-LFAs to IP-LFAs and Prerequisites An LFA for a specific destination is an alternate node to which a packet is sent if the primary next-hop for that destination is unreachable. This alternate node should be capable of forwarding the packet without creating a forwarding loop. LFAs have been defined for IP networks in , and , and such LFAs are referred to as IP-LFAs. BIER-LFAs are similar to IP-LFAs, but a BIER-LFA node must be a BFR. If only a subset of the nodes in the routing underlay are BFRs, some IP-LFAs in the routing underlay may not be usable as BIER-LFAs. To compute BIER-LFAs, network topology and link cost information from the routing underlay are required. This differs from tunnel-based BIER-FRR, where knowledge of the primary BIFTs of a PLR and its BFR-NBRs is sufficient. LFA-based BIER-FRR may reuse IP-LFAs as BIER-LFAs under the following conditions: if an IP-LFA node for the destination of a specific BFER is a BFR, it may be reused as the backup BFR-NBR for that BFER, along with the backup action applied for that IP-LFA at the IP layer. A normal IP-LFA corresponds to the backup forwarding action Direct, a remote IP-LFA to Tunnel, and a TI-IP-LFA to Explicit.

Definition of BIER-LFAs As with IP-LFAs, there are several types of BIER-LFAs: A BFR is considered a normal BIER-LFA for a specific BFER if it is directly connected to the PLR and: the BFER can be reached from it through the BIER domain. both the path from the PLR to the BFR and the path from the BFR to the BFER are disjoint from the primary path from the PLR to the primary BFR-NBR. These paths: may include the primary BFR-NBR for link protection. must not include the primary BFR-NBR for node protection. A BFR is considered a remote BIER-LFA for a specific BFER if it is not directly connected to the PLR, can be reached via a tunnel from the PLR, and satisfies the aforementioned conditions 1 and 2. A BFR is considered a TI-BIER-LFA for a specific BFER if it is not directly connected to the PLR, cannot be reached via a tunnel from the PLR, but is reachable from the PLR via an explicit path (e.g., with the assistance of a Segment Routing (SR) header), and satisfies the aforementioned conditions 1 and 2. For the protection of some BFERs, one or more normal BIER-LFAs may be available at a specific PLR. For the protection of other BFERs, only remote or TI-BIER-LFAs may be available. There may also be BFERs which can be protected only through TI-BIER-LFAs. The backup forwarding actions for rerouting BIER packets depending on the type of BIER-LFA are: For normal BIER-LFA: Direct For remote BIER-LFA: Tunnel For TI-BIER-LFA: Explicit

Protection Coverage of BIER-LFA Types Protection coverage refers to the set of BFERs that can be protected with a desired level of protection by a particular type of BIER-LFA. The BIER-LFA types exhibit the following characteristics: Normal BIER-LFAs The protection coverage is the least as some or many BFERs may not be protected at the desired protection level or at all. Redundant packet copies are avoided. There is no encapsulation overhead. Remote BIER-LFAs They enhance the protection coverage of normal BIER-LFAs. Redundant packet copies may occur on a link, similar to tunnel-based BIER-FRR. The encapsulation overhead is similar to that of tunnel-based BIER-FRR. TI-BIER-LFAs They complement the protection coverage of normal and remote BIER-LFAs to achieve 100% coverage. Redundant packets may occur on a link, similar to tunnel-based BIER-FRR. The encapsulation overhead is similar or equivalent to that of tunnel-based BIER-FRR, depending on the FRR mechanism employed in the routing underlay. There is increased complexity as segment routing, or some other forms of explicit tunnels, needs to be supported by the routing underlay.

Sets of Supported BIER-LFAs Normal BIER-LFAs are the simplest option, as they do not require tunneling or explicit paths. Remote BIER-LFAs offer greater capabilities but introduce additional header overhead and require more functionality from the PLR. TI-BIER-LFAs are the most complex BIER-LFAs, necessitating the use of explicit paths. When implementing LFA-based BIER-FRR, it is essential to specify the set of supported BIER-LFAs. The available options are as follows: Option 1: Only normal BIER-LFAs are supported. Option 2: Both normal and remote BIER-LFAs are supported. Option 3: All types of BIER-LFAs are supported. Options 1 and 2 may not be able to protect the reachability of all BFERs against all single link failures and all single node failures.

Link Protection In the following, LFA-based BIER-FRR with link protection is illustrated. Thereby, normal BIER-LFAs are prioritized over remote LFAs, and remote BIER-LFAs are preferred over TI-BIER-LFAs. Depending on the specific PLR, simple BIER-LFAs are sufficient, remote BIER-LFAs are needed, or even TI-BIER-LFAs to protect the reachability of all BFERs against single link failures. If the link between B1 and B6 fails, B1 cannot reach the BFERs B4, B5, B6, and B7 via their primary BFR-NBR. Consequently, B1 forwards their traffic via the backup BFR-NBR B2, along with the traffic for B2 and B3, as B2 is their primary BFR-NBR. In this scenario, the backup F-BM is set to 1111110. Similarly, if the link between B1 and B2 fails, B1 routes all traffic to B6, with the backup F-BM also set to 1111110. B1 requires only normal BIER-LFAs to protect all BFERs. However, this situation can vary significantly for other BFRs. and present the backup BIFTs for B7 and B5, respectively. BFR B7 requires one normal BIER-LFA, three remote BIER-LFAs, and two TI-BIER-LFAs to protect all BFERs. BFR B5 requires one normal BIER-LFA, one remote BIER-LFA, and four TI-BIER-LFAs as backup BFR-NBRs. Thus, depending on the set of supported BIER-LFAs, it may not be possible to protect all BFERs using BIER-FRR. Consider a scenario where B7 holds a BIER packet with destinations {B1, B4, B5, B6}. If the link between B7 and B6 fails, the packet copy for B1 is sent to B2 using the backup forwarding action Direct, the packet copy for B4 is tunneled via B2 to B3, and the packet copies for B5 and B6 are sent via explicit paths to B4 and B1, respectively. Since these packet copies have different next-hops on the BIER layer, all of them must be transmitted, resulting in three redundant copies.

B6 | +------+----------+--------+-----------+---+-----------------+ | 2 | 0000110 | B1 | Tunnel | | Link B1->B2 | +------+----------+--------+-----------+---+-----------------+ | 3 | 0000110 | B1 | Tunnel | | Link B1->B2 | +------+----------+--------+-----------+---+-----------------+ | 4 | 0001000 | B3 | Tunnel | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ | 5 | 0010000 | B4 | Explicit | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ | 6 | 0100000 | B1 | Explicit | | Link B1->B6 | +------+----------+--------+-----------+---+-----------------+ ]]>

B6 | +------+----------+--------+-----------+---+-----------------+ | 2 | 1100011 | B3 | Explicit | | Link B5->B6 | +------+----------+--------+-----------+---+-----------------+ | 3 | 0000100 | B4 | Direct | | Link B5->B6 | +------+----------+--------+-----------+---+-----------------+ | 4 | 0001000 | B3 | Tunnel | | Link B5->B4 | +------+----------+--------+-----------+---+-----------------+ | 6 | 1100011 | B3 | Explicit | | Link B5->B6 | +------+----------+--------+-----------+---+-----------------+ | 7 | 1100011 | B3 | Explicit | | Link B5->B6 | +------+----------+--------+-----------+---+-----------------+ ]]>

Node Protection To determine the backup forwarding entries for node protection, it is necessary to conduct a case-by-case analysis of the BFER to be protected. If the BFER is the same as its primary BFR-NBR, node protection is not feasible for that BFER, and link protection must be applied instead. In all other cases, the BFER should be protected by a node-protecting BIER-LFA. In this context, normal BIER-LFAs are prioritized over remote BIER-LFAs, and remote BIER-LFAs are preferred over TI-BIER-LFAs. Depending on the set of supported BIER-LFAs, it may not be possible to protect certain BFERs. illustrates B1's backup BIFT for LFA-based BIER-FRR with node protection, using the network example provided in .

As B6 serves as the primary BFR-NBR for BFER B6, only link protection can be applied. Consequently, B2 is utilized as a normal, link-protecting BIER-LFA to safeguard B6. Similarly, as B2 is the primary BFR-NBR for BFER B2, B2 is protected with B6 as its normal, link-protecting BIER-LFA. BFER B7 is protected against the failure of node B6 by using B2 as its normal, node-protecting BIER-LFA, as B2 has a shortest path to B7 that does not traverse B6. The backup F-BMs for BFERs B6 and B7 are set to {B2, B6, B7}, as traffic for these BFERs is routed via link B1->B2 with the backup forwarding action Direct when B6 is unreachable. BFER B4 cannot be reached via a normal LFA when BFR B6 fails. However, B3 serves as a remote, node-protecting BIER-LFA for BFER B4, as B3 has a shortest path to B4, is reachable from B1 via a shortest path, and the resulting backup path from B1 to B4 does not traverse B6. Similarly, B4 serves as a remote LFA for BFER B3 if BFR B2 fails. BFER B5 is neither reachable through a normal BIER-LFA nor through a remote BIER-LFA when BFR B6 fails. However, B4 acts as a node-protecting TI-BIER-LFA for BFER B5 as B4 is reachable through the explicit path B1->B2->B3->B4 and has a shortest path to B5 that does not traverse B6. Consider a scenario where B1 holds a BIER packet with destinations {B4, B5, B6}. If the link between B1 and B2 fails, the packet copy for B1 is sent to B2 using the backup forwarding action Direct, a packet copy for B4 is tunneled via B2, and a packet copy for B5 is sent via an explicit path to B4. Since these packet copies have different next-hops on the BIER layer, all of them must be transmitted, resulting in two redundant copies.

Optimization Potential to Reduce Redundant BIER Packets in Failure Cases Redundant packets can occur with LFA-based BIER-FRR when BIER packets are transmitted over a specific link in different forms, including: Directly sent BIER packets (either primary transmission or reroute to a normal BIER-LFA). BIER packets encapsulated for transmission to a specific BFR-NBR (either tunneled primary transmission or reroute to a remote BIER-LFA). BIER packets routed with an encoded explicit path (reroute to a TI-LFA). When different remote BIER-LFAs are utilized, multiple redundant packets may be generated. A similar situation can arise with TI-BIER-LFAs. However, some redundant packets can be mitigated if remote BIER-LFAs or TI-BIER-LFAs are selected such that they can protect multiple BFERs, thereby reducing the need for additional remote BIER-LFAs or TI-BIER-LFAs. This approach, while potentially leading to longer backup paths, introduces a new optimization objective for the selection of remote or TI-BIER-LFAs, which does not exist in IP-FRR. The relevance of this optimization may vary depending on the specific use case. To illustrate this optimization potential, consider LFA-based BIER-FRR with link protection for B7, as described in its backup BIFT in . As noted in , B7 needs to transmit four copies to forward a packet to {B1, B4, B5, B6}. If the more complex TI-BIER-LFA B4 is chosen to protect BFER B4 instead of the remote BIER-LFA B3, only two redundant copies need to be transmitted.

Comparison This section first addresses the differences between IP-LFAs for IP-FRR and BIER-LFAs for BIER-FRR. It then examines the advantages and disadvantages of tunnel-based and LFA-based BIER-FRR.

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.

Advantages and Disadvantages of Tunnel-Based BIER-FRR

Advantages The computation of backup forwarding entries for tunnel-based BIER-FRR is straightforward, requiring only the primary BIFTs of a PLR and its BFR-NBRs. No routing information from the routing underlay is needed. The forwarding action "Explicit" is not required for tunnel-based BIER-FRR. However, depending on the underlay, explicit forwarding may still be utilized to achieve FRR in the underlay.

Disadvantages Tunnel-based BIER-FRR relies on the presence of a FRR mechanism in the underlay. Its protection level is constrained by the protection level provided by the underlay. For instance, if the underlay supports only link protection, tunnel-based BIER-FRR cannot offer node protection. Redundant packet copies may occur in tunnel-based BIER-FRR. Backup paths may be longer than with LFA-based BIER-FRR. A tunneling header is required for any rerouting, resulting in additional header overhead.

Advantages and Disadvantages of LFA-Based BIER-FRR

Advantages LFA-based BIER-FRR does not depend on any fast protection mechanisms in the underlay. Therefore, it can provide superior protection at the BIER layer compared to the IP layer, particularly if LFA-based BIER-FRR utilizes BIER-LFAs with a higher protection level than those used in LFA-based IP-FRR. For example, the underlay may only offer FRR with link protection, while BIER-FRR can provide node protection for BIER traffic. LFA-based BIER-FRR avoids header overhead for normal BIER-LFAs.

Disadvantages The computation of backup forwarding entries requires routing information from the underlay. The computation of backup forwarding entries is more complex when some nodes in the underlay are not BFRs because then BIER-LFAs differ from IP-LFAs. The "Tunnel" forwarding action is required to protect certain BFERs, which adds header overhead. The "Explicit" forwarding action is necessary to achieve full protection coverage in some topologies; without it, only partial protection coverage is possible. This requires support for explicit paths, such as Segment Routing. More remote BIER-LFAs and TI-BIER-LFAs are needed compared to IP-FRR if some nodes in the routing underlay are not BFRs. Redundant packet copies may occur in LFA-based BIER-FRR, though this is less frequent than with tunnel-based BIER-FRR as simple BIER-LFAs do not require a tunnel.

Security Considerations This specification does not introduce additional security concerns beyond those already discussed in the BIER architecture along with the IP FRR and LFA specifications.

IANA Considerations No requirements for IANA.

Acknowledgments The authors would like to thank Daniel Merling, Jeffrey Zhang, Tony Przygienda and Shaofu Peng for their comments to this work. A special thank you to Gunter van de Velde for his extensive editing to help bring this document to publication.

This document describes the use of loop-free alternates to provide local protection for unicast traffic in pure IP and MPLS/LDP networks in the event of a single failure, whether link, node, or shared risk link group (SRLG). The goal of this technology is to reduce the packet loss that happens while routers converge after a topology change due to a failure. Rapid failure repair is achieved through use of precalculated backup next-hops that are loop-free and safe to use until the distributed network convergence process completes. This simple approach does not require any support from other routers. The extent to which this goal can be met by this specification is dependent on the topology of the network. [STANDARDS-TRACK] As IPTV deployments grow in number and size, service providers are looking for solutions that minimize the service disruption due to faults in the IP network carrying the packets for these services. This document describes a mechanism for minimizing packet loss in a network when node or link failures occur. Multicast-only Fast Reroute (MoFRR) works by making simple enhancements to multicast routing protocols such as Protocol Independent Multicast (PIM) and Multipoint LDP (mLDP). This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bit string in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The procedures for forwarding a packet based on its BIER header are specified in this document. Elimination of the per-flow state and the explicit tree-building protocols results in a considerable simplification. This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms. This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK] This document defines RSVP-TE extensions to establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. These mechanisms enable the re-direction of traffic onto backup LSP tunnels in 10s of milliseconds, in the event of a failure. Two methods are defined here. The one-to-one backup method creates detour LSPs for each protected LSP at each potential point of local repair. The facility backup method creates a bypass tunnel to protect a potential failure point; by taking advantage of MPLS label stacking, this bypass tunnel can protect a set of LSPs that have similar backup constraints. Both methods can be used to protect links and nodes during network failure. The described behavior and extensions to RSVP allow nodes to implement either method or both and to interoperate in a mixed network. [STANDARDS-TRACK] This document provides a framework for the development of IP fast- reroute mechanisms that provide protection against link or router failure by invoking locally determined repair paths. Unlike MPLS fast-reroute, the mechanisms are applicable to a network employing conventional IP routing and forwarding. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document. [STANDARDS-TRACK] This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source. This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the Point of Local Repair (PLR), reducing the operational need to control the tie-breaks among various FRR options. Futurewei Futurewei China Telecom Verizon Inc. China Mobile University of Tuebingen Yandex LLC Huawei Casa Systems Fujitsu Alef Edge This document describes a mechanism for fast protection against the failure of an egress node of a "Bit Index Explicit Replication" (BIER) domain. It is called BIER egress protection. It does not require any per-flow state in the core of the domain. With BIER egress protection the failure of a primary BFER (Bit Forwarding Egress Router) is protected with a backup BFER such that traffic destined to the primary BFER in the BIER domain is fast rerouted by a neighbor BFR to the backup BFER on the BIER layer. The mechanism is applicable if all BIER traffic sent to the primary BFER can reach its destination also via the backup BFER. It is complementary to BIER- FRR which cannot protect against the failure of a BFER. Individual Cisco Systems Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options.

Non-working FRR options

BIER-in-BIER encapsulation is again the example shown in . 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.

Changelog [RFC-Editor: Please remove this section].

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.

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.

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," ?

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/

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

Contributors China Telecom

Beiqijia Town, Changping District Beijing 102209 China wangaj3@chinatelecom.cn

Verizon Inc.

13101 Columbia Pike Silver Spring MD 20904 USA 301 502-1347 gyan.s.mishra@verizon.com

China Mobile

liuyisong@chinamobile.com

Casa Systems

United States of America yfan@casa-systems.com

Fujitsu

United States of America liulei.kddi@gmail.com

Alef Edge

United States of America xufeng.liu.ietf@gmail.com

China gengxuesong@huawei.com