[Bier] Pre-IETF Last-Call review of for draft-ietf-bier-frr-04

["Gunter van de Velde (Nokia)" <[e-mail]>]

# Gunter Van de Velde, RTG AD, comments for draft-ietf-bier-frr-04.txt

## Many thanks to Zheng (Sandy) Zhang for the shepherd writeup.

## This is a shepherding AD draft review before starting the process of the IETF LC.

## The shepherd write-up suggested a verification round with the rtgwg due to the experience of LFA in that WG. 

  "The work on LFA-Based BIER-FRR is aligned with LFAs for IP FRR. Therefore, 
  it should be reviewed by someone in rtgwg."

This seems a sensible request to comply towards. I performed a search in rtgwg and that yielded no review request:
https://mailarchive.ietf.org/arch/browse/rtgwg/?q=draft-ietf-bier-frr

## idnits revealed some outdated references (caused due the delay of the Shepherding AD review)

## The draft could use a section explaining the acronyms used. While these may be well known in the BIER technology area, it may not be the same for technology generalists. Please add a section or at least reference documents where terminology is defined and explained.

## the original text uses the word 'we' sporadically. i tried to clean that up with alternate suggested text removing the 'we' construct. It is to me unclear who exactly is 'we', is that the authors, is it the WG is that the IETF, is that a subgroup of authors?

## in the next part you will find suggestions for rewritten text to help the structure and technical precision of the content. I tried to keep the original intent. You will find the review rather lengthy, however i hope you find processing the suggestions and using copy/paste convenient

## In section "3.3.  Primary BIFT and Failure-Specific Backup BIFTs" it is unclear to me how the node protection failure-specific is illustrated. I see in the last column of figure 6 the textblob "Comment: protects: failure of some" but how is this correlated with node protection of B6? I am wondering if there is a column missing or if there is unclear description?

## section 5.1.3.  about implementation experience is better positioned in a document appendix. In few years the section is caught up by time and no longer relevant, while the remainder of the text keeps holding value.

## section 7. Security considerations is rather compact. The solution in the draft uses tunnels and LFA technology and these may have implicit relevant security considerations. I took liberty to add a set of those considerations at the end of this review message to look at and potentially validate against usage in a BIER enabled environment.

## the line numbering in this review is based upon the numbers from the idnits report
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bier-frr-04.txt

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

17	Abstract
18
19	   BIER is a scalable multicast overlay that utilizes a routing
20	   underlay, e.g., IP, to build up its Bit Index Forwarding Tables
21	   (BIFTs).  This document proposes Fast Reroute for BIER (BIER-FRR).
22	   It protects BIER traffic after detecting the failure of a link or
23	   node in the core of a BIER domain until affected BIFT entries are
24	   recomputed after reconvergence of the routing underlay.  BIER-FRR is
25	   applied locally at the point of local repair (PLR) and does not
26	   introduce any per-flow state.  The document specifies nomenclature
27	   for BIER-FRR and gives examples for its integration in BIER
28	   forwarding.  Furthermore, it presents operation modes for BIER-FRR.
29	   Link and node protection may be chosen as protection level.
30	   Moreover, the backup strategies tunnel-based BIER-FRR and LFA-based
31	   BIER-FRR are defined and compared.

[minor]
My preference is to keep the abstract focussed around the content and objective of the draft itself. I woudl expect that readers of the draft have awareness of BIER already, Hence maybe the following alternate abstract:

"
This document describes a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks. The proposed solution enhances the resiliency of BIER by providing a method to quickly reroute traffic in the event of a link or node failure, thereby minimizing packet loss and service disruption. The document details the procedures for detecting failures and selecting backup paths within the BIER domain, ensuring that multicast traffic continues to reach its intended destinations without requiring per-flow state or additional signaling. This FRR mechanism is designed to integrate seamlessly with existing BIER operations, offering a robust solution for improving network reliability.
"


131
132	   BIER packets are usually forwarded without an outer IP header.  If a
133	   link or node fails, the corresponding BFR neighbor (BFR-NBR) is no
134	   longer reachable.  Fast reroute (FRR) mechanisms in the routing
135	   underlay, e.g., IP-FRR, apply only to IP packets so that BIER traffic
136	   would be dropped.  BIER traffic can be delivered again only after
137	   reconvergence of the routing underlay and recalculation of the BIFT.
138	   Thus, tunneling BIER packets can help to reach the BFR-NBR in case of
139	   a link failure by leveraging FRR capabilities of the routing underlay
140	   if such mechanisms are available.  However, this does not help in
141	   case of a node failure.  Then, all destinations having the failed
142	   node as BFR-NBR cannot be reached anymore.  As BIER carries multicast
143	   traffic which has often realtime requirements, there is a particular
144	   need to protect BIER traffic against too long outages after failures.
145
146	   In this document we propose nomenclature for Fast Reroute in BIER
147	   (BIER-FRR).  As soon as a BFR detects a BFR-NBR is unreachable, BIER-
148	   FRR enables a BFR to quickly reroute affected BIER packets with the
149	   help of backup forwarding entries.  To avoid redundant packets,
150	   backup forwarding entries should be processed prior to normal
151	   forwarding entries.  To achieve that goal, two possible
152	   representations for backup forwarding entries are proposed.
153
154	   The protection level can be either link protection or node
155	   protection.  Link protection protects only the failure of a link.  It
156	   is simple but may not work if a BFR fails.  Node protection is more
157	   complex but also protects against the failure of BFRs.  The backup
158	   strategy determines the selection of the backup forwarding entries.
159
160	   Examples for backup strategies are tunnel-based BIER-FRR and LFA-
161	   based BIER-FRR
162
163	   *  Tunnel-based BIER-FRR leverages mechanisms of the routing underlay
164	      for FRR purposes.  The routing underlay restores connectivity
165	      faster than BIER as a reconverged routing underlay is prerequisite
166	      for recalculation of the BIFT.  If the routing underlay leverages
167	      FRR mechanisms, its forwarding ability is restored long before
168	      reconvergence is completed.  To leverage fast restoration of the
169	      routing underlay, BIER traffic affected by a failure is tunneled
170	      over the routing underlay.
170
172	   *  LFA-based BIER-FRR reroutes BIER traffic to alternative neighbors
173	      in case of a failure.  It utilizes the principles of IP-FRR but
174	      requires that LFAs are BFRs.  Normal BIER-LFAs can be reached
175	      without tunneling, remote BIER-LFAs utilize a tunnel, and
176	      topology-independent BIER-LFAs leverage explicit paths to reach
177	      the backup BFR-NBR.  In contrast to tunnel-based FRR, LFA-based
178	      BIER-FRR does not require fast reroute mechanisms in the routing
179	      underlay.
180
181	   BIER-FRR as presented in this document follows a primary/backup path
182	   principle, also known as 1:1 protection.  It is opposite to 1+1
183	   protection which denotes a live-live protection principle.  This has
184	   been considered for BIER in [BrAl17].

[minor]
proposed rewrite:

"
Typically, BIER packets are forwarded without an outer IP header. Consequently, if a link or node failure occurs, the corresponding BFR Neighbor (BFR-NBR) becomes unreachable. Fast Reroute (FRR) mechanisms in the routing underlay, such as IP-FRR, apply exclusively to IP packets, leading to potential loss of BIER traffic. BIER traffic can only be restored after the routing underlay has reconverged and the BIFT has been recalculated. Tunneling BIER packets can serve as a solution to reach the BFR-NBR in the case of a link failure by leveraging the FRR capabilities of the routing underlay, provided such mechanisms are available. However, this approach does not address node failures, as all destinations that rely on the failed node as their BFR-NBR become unreachable. Given that BIER often carries multicast traffic with real-time requirements, there is a particular need to protect BIER traffic against prolonged outages following failures.

This document introduces a nomenclature for Fast Reroute in BIER (BIER-FRR). Upon detecting that a BFR-NBR is unreachable, BIER-FRR enables a BFR to quickly reroute affected BIER packets using backup forwarding entries. To avoid the generation of redundant packets, backup forwarding entries should be processed before normal forwarding entries. To achieve this, two potential representations for backup forwarding entries are proposed.

The protection level offered by BIER-FRR can be either link protection or node protection. Link protection is limited to safeguarding against link failures and is simpler to implement but may not be effective if a BFR itself 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.

Examples of backup strategies include tunnel-based BIER-FRR and Loop-Free Alternate (LFA)-based BIER-FRR:

* Tunnel-based BIER-FRR: This approach leverages the mechanisms of the routing underlay for FRR purposes. The routing underlay typically restores connectivity faster than BIER, as the reconvergence of the routing underlay is a prerequisite for the recalculation of the BIFT. When the routing underlay utilizes FRR mechanisms, its forwarding capabilities are restored well before reconvergence is completed. To benefit from the rapid restoration of the routing underlay, BIER traffic affected by a failure is tunneled over the routing underlay.

* LFA-based BIER-FRR: This approach reroutes BIER traffic to alternative neighbors in the event of a failure. It applies the principles of IP-FRR, requiring that LFAs are also BFRs. Normal BIER-LFAs can be reached without tunneling, remote BIER-LFAs employ a tunnel, and topology-independent BIER-LFAs use explicit paths to reach the backup BFR-NBR. Unlike tunnel-based FRR, LFA-based BIER-FRR does not depend on fast reroute mechanisms in the routing underlay.

The BIER-FRR mechanism described in this document adheres to a primary/backup path model, also known as 1:1 protection, which contrasts with the 1+1 protection model, where traffic is duplicated across both primary and backup paths, as explored for BIER in [BrAl17].
"

192	2.1.  Definition of Forwarding Actions
193
194	   A BFR-NBR is directly connected if it is a next hop on the network
195	   layer, i.e., if it can be reached via the link layer technology.
196	   Otherwise, the BFR-NBR is indirectly connected.
197
198	   We define the following forwarding actions.
199
200	   *  Plain: Sends the mere BIER packet to a BFR-NBR via a direct link
201	      and without a tunnel header.  That means, the packet is not sent
202	      over the routing underlay.
203
204	   *  Tunnel: Encapsulates the BIER packet with a tunnel header towards
205	      a BFR-NBR and sends it over the routing underlay.
206
207	   *  Explicit: Forwards the packet over an explicit path to a BFR-NBR.
208	      The path information must be given.  If segment routing is used
209	      for this purpose, the segment IDs (SIDs) must be given.  Two
210	      forwarding actions of type Explicit are equal only if they share
211	      the same explicit path.
212
213	   The forwarding actions in the BIFT as proposed in [RFC8279] are given
214	   implicitly as they are derived from the connectedness of the BFR-NBR.
215	   If the BFR-NBR is directly connected, the forwarding action is Plain.
216	   If the BFR-NBR is not directly connected, the forwarding action is
217	   Tunnel.

[minor]
proposed rewrite:

"
A BFR-NBR is considered directly connected if it is a next hop at the network layer, meaning it can be reached via link layer technology. 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 header. This indicates that the packet is not routed through the underlying network.

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

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

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

219	2.2.  Definition of Backup Forwarding Entries
220
221	   The BIFT as proposed in [RFC8279] contains a F-BM and a BFR-NBR for a
222	   specific BFER.  They constitute a primary forwarding entry.  BIER-FRR
223	   extends this regular BIFT by additional columns containing backup
224	   forwarding entries.  A backup forwarding entry contains
225
226	   *  a backup F-BM (BF-BM),
227
228	   *  a backup BFR-NBR (BBFR-NBR),
229
230	   *  a backup forwarding action (BFA), and
231
232	   *  a backup entry active (BEA) flag.
233
234	   Backup F-BM and backup BFR-NBR have the same structure as their
235	   primary counterparts.  The backup forwarding action is a forwarding
236	   action as defined in Section 2.1.  The BEA flag indicates whether the
237	   backup forwarding entry is active.  When it is active, the backup
238	   F-BM, backup BFR-NBR, and the backup forwarding action are used for
239	   the forwarding of BIER packets instead of the primary forwarding
240	   entry.  The structure of the extended BIFT is given in Figure 1.
241
242	       +--------+------+---------+--------+----------+--------+----+
243	       | BFR-id | F-BM | BFR-NBR | BF-BM  | BBFR-NBR |  BFA   | BEA|
244	       +========+======+=========+========+==========+========+====+
245	       |  ...   |  ... |   ...   |   ...  |   ...    |  ...   |    |
246	       +--------+------+---------+--------+----------+--------+----+
247
248	       Figure 1: Structure of an extended BIFT with backup forwarding
249	                                  entries.
250
251	   The primary action is not given in the BIFT as it is derived from the
252	   BFR-NBR.  In contrast, the backup forwarding action is given in the
253	   extended BIFT.  Moreover, an explicit path must be indicated in case
254	   of forwarding action Explicit.  However, explicit paths are
255	   implementation-specific and, therefore, this information is not
256	   indicated in the table.  The values for the backup BFR-NBR and the
257	   backup action depend on the desired protection level and the backup
258	   strategy.  Examples for them are described in Section 5.1 and
259	   Section 5.2.  The backup F-BM depends on the backup BFR-NBR.  Its
260	   computation is explained in Section 2.4.

[minor]
proposed rewrite:

"
The BIFT as proposed in [RFC8279] includes a Forwarding Bit Mask (F-BM) and a BFR-NBR for a specific BFER. These elements constitute a primary forwarding entry. The BIER-FRR (Fast Reroute) mechanism extends the conventional BIFT by introducing additional columns that contain backup forwarding entries. A backup forwarding entry comprises the following components:

* Backup Forwarding Bit Mask (BF-BM)
* Backup BFR Neighbor (BBFR-NBR)
* Backup Forwarding Action (BFA)
* Backup Entry Active (BEA) Flag

The BF-BM and BBFR-NBR share the same structure as their primary counterparts. The BFA is defined as a forwarding action according to Section 2.1. The BEA flag indicates whether the backup forwarding entry is currently active. When active, the BF-BM, BBFR-NBR, and BFA are utilized for forwarding BIER packets in place of the primary forwarding entry. The structure of the extended BIFT is illustrated in Figure 1.

   	       +--------+------+---------+--------+----------+--------+----+
   	       | BFR-id | F-BM | BFR-NBR | BF-BM  | BBFR-NBR |  BFA   | BEA|
   	       +========+======+=========+========+==========+========+====+
   	       |  ...   |  ... |   ...   |   ...  |   ...    |  ...   |    |
   	       +--------+------+---------+--------+----------+--------+----+

   	       Figure 1: Structure of an extended BIFT with backup forwarding
   	                                  entries.

The primary action is not explicitly stated in the BIFT, as it is derived from the BFR-NBR. In contrast, the backup forwarding action is explicitly defined in the extended BIFT. Additionally, in the case of an Explicit forwarding action, the explicit path must be indicated. However, since explicit paths are implementation-specific, this information is not detailed in the table. The values for the backup BFR-NBR and the backup action depend on the desired level of protection and the chosen backup strategy. Examples of these are provided in Sections 5.1 and 5.2. The Backup Forwarding Bit Mask (BF-BM) is determined based on the backup BFR-NBR, and its computation is described in Section 2.4.
"

279	2.4.  Computation of the Backup F-BM
280
281	   The primary F-BM of a specific BFER indicates all BFERs that share
282	   the same primary BFR-NBR.  The backup F-BM of a specific BFER
283	   indicates
284
285	   *  all BFERs that share the primary and backup BFR-NBR of the
286	      specific BFER and
287
288	   *  all BFERs that have the backup BFR-NBR of the specific BFER as
289	      primary BFR-NBR.

[minor]
proposed rewrite:

"
The primary F-BM of a specific BFER identifies all BFERs that share the same primary Bit-Forwarding Router Neighbor (BFR-NBR). The backup F-BM for a specific BFER is computed to indicate:

A* ll 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.
"

291	3.  Representations for BIER-FRR Forwarding Data
292
293	   We show that backup entries need to be used first to reduce the
294	   number of redundant packets in the single extended BIFT (presented in
295	   Section 2.2).  This may be hard or cannot be achieved on some
296	   hardware platforms.  Therefore, two alternate representations of
297	   forwarding entries are proposed.  The first is a primary BIFT and
298	   single backup BIFT (SBB).  The second is a primary BIFT and multiple
299	   failure-specific backup BIFTs (FBB).

[minor]
proposed rewrite:

"
To minimize the occurrence of redundant packets, it is essential that backup entries are prioritized for use within the single extended BIFT, as described in Section 2.2. However, implementing this priority may be challenging or infeasible on certain hardware platforms. Consequently, two alternative representations of forwarding entries are proposed. The first representation involves a primary BIFT and a Single Backup BIFT (SBB). The second representation comprises a primary BIFT along with multiple Failure-Specific Backup BIFTs (FBB).
"

301	3.1.  Potential Emergence of Redundant Packets
302
303	   The BIER forwarding procedure in failure-free scenarios avoids
304	   redundant packets, i.e., it ensures that at most a single copy is
305	   sent per link for every BIER packet.  However, this property might be
306	   violated when BIER-FRR as presented in Section 2 is applied to
307	   protect against a failure.
308
309	   Figure 2 shows an example of a BIER network.  BFRs have the prefix
310	   "B" and are numbered by their BFR-ids.  To simplify the example,
311	   every BFR is a BFER and its bit position in the bitstring equals its
312	   BFR-id.  The number on a link is its cost which is used by the
313	   routing underlay for computing the shortest paths.
314
315	              1              1
316	        B1 --------- B6 ------------ B5       BFR Bi is BFER
317	        |            |               |       (i = 1,2,3,4,5,6,7;
318	        |            |               |        i is BFR-id of Bi)
319	      2 |            | 1             |
320	        |      1     |               | 1     cost of link B1-B2 is 2
321	        B2 --------- B7              |       cost of link B3-B4 is 4
322	        |                            |       cost of other links is 1
323	      1 |                            |
324	        |                  4         |
325	       B3 ------------------------- B4
326	                      Figure 2: BIER network example.
327
328	   The extended BIFT with backup forwarding entries for LFA-based BIER-
329	   FRR with link protection built by BFR B1 is illustrated in Figure 3.
330
331	      +------+----------+-------+----------+--------+----------+---+
332	      |BFR-id|   F-BM   |BFR-NBR|  BF-BM   |BBFR-NBR|   BFA    |BEA|
333	      +======+==========+=======+==========+========+==========+===+
334	      |   2  | 0000110  |  B2   | 1111110  |   B6   |  Plain   |   |
335	      +------+----------+-------+----------+--------+----------+---+
336	      |   3  | 0000110  |  B2   | 1111110  |   B6   |  Plain   |   |
337	      +------+----------+-------+----------+--------+----------+---+
338	      |   4  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |   |
339	      +------+----------+-------+----------+--------+----------+---+
340	      |   5  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |   |
341	      +------+----------+-------+----------+--------+----------+---+
342	      |   6  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |   |
343	      +------+----------+-------+----------+--------+----------+---+
344	      |   7  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |   |
345	      +------+----------+-------+----------+--------+----------+---+
346
347	    Figure 3: B1's extended BIFT for LFA-based FRR with link protection.
348
349	   We show how redundant packets can occur in case of a failure.  To
350	   that end, we consider the extended BIFT for BFR 1 in Figure 3.  It
351	   has backup forwarding entries for LFA-based FRR and link protection.
352	   For a BIER packet with destinations B2 and B6 (i.e., bitstring
353	   0100010), BFR B1 sends a single packet copy on link B1-B2 and on link
354	   B1-B6 in the absence of a failure.
355
356	   When the link B1-B6 fails, B1 as a PLR detects the failure.
357	   Therefore, B1 sets the BEA flag for all destinations that have B6 as
358	   BFR-NBR.  We consider again that B1 sends a BIER packet to B2 and B6.
359	   At first, it sends a copy with bitstring 0000010 to B2 using the
360	   corresponding primary forwarding entry in the extended BIFT in
361	   Figure 3.
362
363	   Then, B1 sends another copy of the packet with bitstring 0100000 for
364	   B6 to B2 using the backup forwarding entry since the BEA flag is
365	   activated.
366
367	   This is a second (redundant) copy over the same link B1-B2.  It can
368	   be prevented if the backup forwarding entry is used first.  When
369	   using the backup forwarding entry, B1 sends only a single copy of the
370	   packet with bitstring 0100010 to B2.  It will not send any copy of
371	   the packet to B2 again since the bitstring in the packet will be all
372	   cleaned by the BF-BM 1111110.  Thus, prioritized processing of BFERs
373	   with unreachable BFR-NBRs helps to reduce redundant packet copies.

[minor]
proposed rewrite:

"
The BIER forwarding procedure in failure-free scenarios is designed to avoid the generation of redundant packets, ensuring that at most a single copy is transmitted per link for each BIER packet. However, this property may be compromised when BIER-FRR, as described in Section 2, is employed to provide protection against a failure.

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

          1              1
    B1 --------- B6 ------------ B5       BFR Bi is BFER
    |            |               |       (i = 1,2,3,4,5,6,7;
    |            |               |        i is BFR-id of Bi)
  2 |            | 1             |
    |      1     |               | 1     cost of link B1-B2 is 2
    B2 --------- B7              |       cost of link B3-B4 is 4
    |                            |       cost of other links is 1
  1 |                            |
    |                  4         |
   B3 ------------------------- B4
                  
    Figure 2: BIER network example.

The extended BIFT with backup forwarding entries for LFA-based BIER-FRR with link protection, as constructed by BFR B1, is illustrated in Figure 3.

   +------+----------+-------+----------+--------+----------+---+
   |BFR-id|   F-BM   |BFR-NBR|  BF-BM   |BBFR-NBR|   BFA    | BEA|
   +======+==========+=======+==========+========+==========+===+
   |   2  | 0000110  |  B2   | 1111110  |   B6   |  Plain   |    |
   +------+----------+-------+----------+--------+----------+---+
   |   3  | 0000110  |  B2   | 1111110  |   B6   |  Plain   |    |
   +------+----------+-------+----------+--------+----------+---+
   |   4  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |    |
   +------+----------+-------+----------+--------+----------+---+
   |   5  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |    |
   +------+----------+-------+----------+--------+----------+---+
   |   6  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |    |
   +------+----------+-------+----------+--------+----------+---+
   |   7  | 1111000  |  B6   | 1111110  |   B2   |  Plain   |    |
   +------+----------+-------+----------+--------+----------+---+

    Figure 3: B1's extended BIFT for LFA-based FRR with link protection

The emergence of redundant packets during a failure scenario is demonstrated as follows. Consider the extended BIFT for BFR B1 depicted in Figure 3. This BIFT includes backup forwarding entries for LFA-based FRR with link protection. In a failure-free scenario, when forwarding a BIER packet destined for B2 and B6 (bitstring 0100010), BFR B1 sends a single copy of the packet on the link B1-B2 and another on the link B1-B6.

In the event of a failure on link B1-B6, BFR B1, acting as the PLR, detects the failure. Consequently, B1 sets the BEA flag for all destinations that have B6 as their BFR-NBR. If B1 is to send a BIER packet to B2 and B6 under these conditions, it first sends a copy with bitstring 0000010 to B2 using the corresponding primary forwarding entry in the extended BIFT shown in Figure 3.

Subsequently, B1 sends another copy of the packet with bitstring 0100000 to B2 for B6, using the backup forwarding entry, since the BEA flag is activated.

This results in a second (redundant) copy being sent over the same link B1-B2. This redundancy can be avoided if the backup forwarding entry is prioritized. By using the backup forwarding entry first, B1 would send only a single copy of the packet with bitstring 0100010 to B2, and no additional copy would be sent to B2, as the bitstring in the packet would be cleared by the BF-BM 1111110. Therefore, prioritizing the processing of BFERs with unreachable BFR-NBRs helps to reduce the generation of redundant packet copies.
"

375	3.2.  Primary BIFT and Single Backup BIFT
376
377	   The extended BIFT may be separated into two BIFTs.  One is a primary
378	   BIFT and the other is a single backup BIFT.  The primary BIFT is the
379	   same as the regular BIFT.  The backup BIFT contains the backup
380	   forwarding entries, including BF-BM, BBFR-NBR, BFA and BEA in the
381	   extended BIFT.  When a BFR as a PLR detects that BFR-NBR N is
382	   unreachable, it activates the BEA flag for all BFERs in the backup
383	   BIFT that have BFR-NBR as primary BFR-NBR.  When a BFR forwards a
384	   BIER packet, it processes the packet first using the backup BIFT and
385	   then using the primary BIFT.  With this prioritization, the number of
386	   redundant packet copies can be reduced.
387
388	   B1's extended BIFT in Figure 3 is separated into the primary BIFT in
389	   Figure 4 and the single backup BIFT in Figure 5.
390
391	                       +--------+---------+---------+
392	                       | BFR-id |   F-BM  | BFR-NBR |
393	                       +========+=========+=========+
394	                       |   2    | 0000110 |    B2   |
395	                       +--------+---------+---------+
396	                       |   3    | 0000110 |    B2   |
397	                       +--------+---------+---------+
398	                       |   4    | 1111000 |    B6   |
399	                       +--------+---------+---------+
400	                       |   5    | 1111000 |    B6   |
401	                       +--------+---------+---------+
402	                       |   6    | 1111000 |    B6   |
403	                       +--------+---------+---------+
404	                       |   7    | 1111000 |    B6   |
405	                       +--------+---------+---------+
406
407	         Figure 4: B1's primary BIFT for the BIER network example.
408
409	       +------+----------+--------+-----------+---+-----------------+
410	       |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
411	       |      |          |        |           |   |  failure of     |
412	       +======+==========+========+===========+===+=================+
413	       |   2  | 1111110  |   B6   |  Plain    |   |  Link B1->B2    |
414	       +------+----------+--------+-----------+---+-----------------+
415	       |   3  | 1111110  |   B6   |  Plain    |   |  Link B1->B2    |
416	       +------+----------+--------+-----------+---+-----------------+
417	       |   4  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
418	       +------+----------+--------+-----------+---+-----------------+
419	       |   5  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
420	       +------+----------+--------+-----------+---+-----------------+
421	       |   6  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
422	       +------+----------+--------+-----------+---+-----------------+
423	       |   7  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
424	       +------+----------+--------+-----------+---+-----------------+
425
426	          Figure 5: B1's backup BIFT for the BIER network example.
427
428	   Each forwarding entry in the backup BIFT contains BF-BM, BBFR-NBR,
429	   BFA and BEA.  When a BFR-NBR fails, the BEA flag is activated for all
430	   BFERs in the backup BIFT that have BFR-NBR as primary BFR-NBR.  For
431	   example, BFERs B4, B5, B6 and B7 have BFR-NBR B6 as their primary
432	   BFR-NBR.  When BFR-NBR B6 fails, the BEA flag for BFERs B4, B5, B6
433	   and B7 is activated, i.e., the BEA in the last four entries in the
434	   backup BIFT is set to one.

[minor]
proposed rewrite:

"
The extended BIFT can be divided into two distinct BIFTs: one serving as the primary BIFT, and the other as a single backup BIFT. The primary BIFT functions in the same manner as the regular BIFT. The backup BIFT, however, contains the backup forwarding entries, including the BBF-BM, BBFR-NBR, BFA, and BEA flag from the extended BIFT. When a BFR, acting as the PLR, detects that a BFR-NBR has become unreachable, it activates the BEA flag for all BFERs in the backup BIFT that have the affected BFR-NBR as their primary BFR-NBR. When forwarding a BIER packet, the BFR processes the packet using the backup BIFT first, followed by the primary BIFT. This prioritization helps to reduce the number of redundant packet copies.

B1's extended BIFT from Figure 3 is divided into the primary BIFT shown in Figure 4 and the single backup BIFT shown in Figure 5.

   +--------+---------+---------+
   | BFR-id |   F-BM  | BFR-NBR |
   +========+=========+=========+
   |   2    | 0000110 |    B2   |
   +--------+---------+---------+
   |   3    | 0000110 |    B2   |
   +--------+---------+---------+
   |   4    | 1111000 |    B6   |
   +--------+---------+---------+
   |   5    | 1111000 |    B6   |
   +--------+---------+---------+
   |   6    | 1111000 |    B6   |
   +--------+---------+---------+
   |   7    | 1111000 |    B6   |
   +--------+---------+---------+

    Figure 4: B1's primary BIFT for the BIER network example.

   +------+----------+--------+-----------+---+-----------------+
   |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
   |      |          |        |           |   |  failure of     |
   +======+==========+========+===========+===+=================+
   |   2  | 1111110  |   B6   |  Plain    |   |  Link B1->B2    |
   +------+----------+--------+-----------+---+-----------------+
   |   3  | 1111110  |   B6   |  Plain    |   |  Link B1->B2    |
   +------+----------+--------+-----------+---+-----------------+
   |   4  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   5  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   6  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   7  | 1111110  |   B2   |  Plain    |   |  Link B1->B6    |
   +------+----------+--------+-----------+---+-----------------+

    Figure 5: B1's backup BIFT for the BIER network example.

Each forwarding entry in the backup BIFT includes the BF-BM, BBFR-NBR, BFA, and BEA. When a BFR-NBR fails, the BEA flag is activated for all BFERs in the backup BIFT that have the affected BFR-NBR as their primary BFR-NBR. For instance, BFERs B4, B5, B6, and B7 have BFR-NBR B6 as their primary BFR-NBR. If BFR-NBR B6 fails, the BEA flag for BFERs B4, B5, B6, and B7 is activated, setting the BEA in the last four entries in the backup BIFT to one.
"

436	3.3.  Primary BIFT and Failure-Specific Backup BIFTs
437
438	   As an alternative, the information in the extended BIFT may be
439	   represented in a primary BIFT and several, failure-specific backup
440	   BIFTs.  A failure-specific backup BIFT is a backup BIFT for the
441	   unreachability of BFR-NBR N.  A backup BIFT for the failure of N is
442	   simply called a backup BIFT for N.  It has the same structure as the
443	   regular BIFT but has an entry for a backup forwarding action.  Thus,
444	   a BFR has a primary BIFT, which is the same as the regular BIFT, and
445	   a backup BIFT for each of its BFR-NBRs.
446
447	   The BFR uses the primary BIFT to forward BIER packets under failure-
448	   free conditions.  When the BFR as a PLR detects that BFR-NBR N is
449	   unreachable, it uses the backup BIFT for N to forward all BIER
450	   packets.  After the routing underlay has re-converged on the new
451	   network topology, the primary BIFT is re-computed.  Once the re-
452	   computed primary BIFT is installed, it is used to forward all BIER
453	   packets.
454
455	   We illustrate the concept using the example from extended BIFT in
456	   Figure 3.  Figure 4 shows the primary BIFT of B1 in this context.
457	   BFR B1 in Figure 2 has two neighbors: B6 and B2.  B1 has two backup
458	   BIFTs with link protection: one for B6 and another for B2.  B1 has
459	   also two backup BIFTs with node protection.  Figure 6 is B1's backup
460	   BIFT for B6 to react to the unreachability of B1 in a similar way as
461	   with the extended BIFT in Figure 3.
462
463	    +--------+---------+---------+-----------------+-----------------+
464	    | BFR-id |  F-BM   | BFR-NBR |Forwarding Action|Comment: protects|
465	    |        |         |         |                 |  failure of     |
466	    +========+=========+=========+=================+=================+
467	    |    2   | 1111110 |    B2   |   Plain         |                 |
468	    +--------+---------+---------+-----------------+-----------------+
469	    |    3   | 1111110 |    B2   |   Plain         |                 |
470	    +--------+---------+---------+-----------------+-----------------+
471	    |    4   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
472	    +--------+---------+---------+-----------------+-----------------+
473	    |    5   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
474	    +--------+---------+---------+-----------------+-----------------+
475	    |    6   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
476	    +--------+---------+---------+-----------------+-----------------+
477	    |    7   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
478	    +--------+---------+---------+-----------------+-----------------+
479
480	       Figure 6: B1's backup BIFT for B6 for LFA-based BIER FRR with
481	                              link protection.
482
483	   Once B1 as a PLR detects that B6 is unreachable through the link to
484	   B6, it uses the backup BIFT for B6 to forward all BIER packets.  As
485	   this representation is equivalent to the concept of single primary
486	   and single backup BIFT, redundant packets for the same forwarding
487	   action are avoided.

[minor]
proposed rewrite:

"
As an alternative to the single extended BIFT, the information can be represented using a primary BIFT along with several failure-specific backup BIFTs. A failure-specific backup BIFT is associated with the unreachability of a particular BFR-NBR. A backup BIFT for the failure of BFR-NBR N is simply referred to as a backup BIFT for N. This backup BIFT mirrors the structure of the regular BIFT but includes entries for backup forwarding actions. Therefore, a BFR maintains a primary BIFT, identical to the regular BIFT, and a separate backup BIFT for each of its BFR-NBRs.

Under normal, failure-free conditions, the BFR utilizes the primary BIFT to forward BIER packets. Upon detecting that BFR-NBR N has become unreachable, the BFR, acting as the PLR, switches to the backup BIFT for N to forward all BIER packets. Once the routing underlay has re-converged to reflect the updated network topology, the primary BIFT is re-computed. The newly computed primary BIFT is then reinstated for forwarding all BIER packets.

This concept can be illustrated using the example of the extended BIFT in Figure 3. Figure 4 depicts B1's primary BIFT in this context. BFR B1 in Figure 2 has two neighbors: B6 and B2. Consequently, B1 maintains two backup BIFTs with link protection: one for B6 and another for B2. Additionally, B1 also maintains two backup BIFTs with node protection. Figure 6 represents B1's backup BIFT for B6, which is utilized in response to the unreachability of B6, functioning similarly to the extended BIFT shown in Figure 3.

   +--------+---------+---------+-----------------+-----------------+
   | BFR-id |  F-BM   | BFR-NBR |Forwarding Action|Comment: protects|
   |        |         |         |                 |  failure of     |
   +========+=========+=========+=================+=================+
   |    2   | 1111110 |    B2   |   Plain         |                 |
   +--------+---------+---------+-----------------+-----------------+
   |    3   | 1111110 |    B2   |   Plain         |                 |
   +--------+---------+---------+-----------------+-----------------+
   |    4   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
   +--------+---------+---------+-----------------+-----------------+
   |    5   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
   +--------+---------+---------+-----------------+-----------------+
   |    6   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
   +--------+---------+---------+-----------------+-----------------+
   |    7   | 1111110 |    B2   |   Plain         |  Link B1->B6    |
   +--------+---------+---------+-----------------+-----------------+

       Figure 6: B1's backup BIFT for B6 for LFA-based BIER FRR with
                              link protection.

Once B1, as the PLR, detects that B6 has become unreachable via the link to B6, it switches to the backup BIFT for B6 to forward all BIER packets. Since this representation aligns with the concept of a single primary and single backup BIFT, the occurrence of redundant packets for the same forwarding action is avoided.
"

489	4.  Protection Levels
490
491	   Link and node protection may be supported.  Link protection protects
492	   against the failure of an adjacent link while node protection
493	   protects against the failure of a neighboring node and the path
494	   towards that node.  Depending on the supported service, link
495	   protection or node protection may be relevant.  Both protection
496	   levels can be combined with any backup strategy in Section 5.

[minor]
proposed rewrite:

"
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 Section 5.
"


498	4.1.  Link Protection
499
500	   With link protection the backup path avoids the failed link (i.e.,
501	   the failed primary path from the PLR to the primary BFR-NBR,
502	   excluding the primary BFR-NBR), but the backup path may include the
503	   primary BFR-NBR.  Therefore, the backup path is still operational if
504	   the primary path fails.  The disadvantage of link protection is that
505	   it fails if the primary BFR-NBR itself is not operational.  However,
506	   link protection has also advantages.  It often leads to shorter
507	   backup paths than node protection.  In case of tunnel-based BIER-FRR,
508	   link protection causes at most one redundant packet while node
509	   protection can cause more redundant packets.  In case of LFA-based
510	   BIER-FRR, link protection can protect more BFERs with normal BIER-
511	   LFAs than node protection.

[minor]
proposed rewrite:

"
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 remains operational even if the primary path fails. The primary limitation of link protection is its inability to provide protection if the primary BFR-NBR itself becomes inoperative. However, link protection also offers certain advantages. It typically results in shorter backup paths compared to node protection. In the case of tunnel-based BIER-FRR, link protection generates at most one redundant packet, whereas node protection may result in multiple redundant packets. Additionally, for LFA-based BIER-FRR, link protection is more effective in safeguarding a greater number of BFERs using normal BIER-LFAs than node protection.
"

513	4.2.  Node Protection
514
515	   With node protection, the backup path avoids the failed node and the
516	   link to the node (i.e., the failed primary path from the PLR to the
517	   primary BFR-NBR, including the primary BFR-NBR).  Therefore, the
518	   backup path must not include the primary path or the primary BFR-NBR
519	   so that the backup path is still operational if these elements fail.
520	   If a BFER and its primary BFR-NBR are the same, only link protection
521	   is possible for that BFER.  An advantage of node protection is the
522	   improved protection quality compared to link protection.  However,
523	   node protection has also disadvantages.  It often leads to longer
524	   backup paths than link protection.  For tunnel-based BIER-FRR,
525	   possibly more redundant packets are transmitted over a link than with
526	   link protection.  For LFA-based BIER-FRR, possibly fewer BFERs can be
527	   protected with normal BIER-LFAs so that more remote BIER-LFAs or
528	   topology-independent BIER-LFAs are needed which are more complex.

[minor]
proposed rewrite:

"
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 must exclude both the primary path and the primary BFR-NBR to remain operational in the event of their failure. If a BFER and its primary BFR-NBR are the same, only link protection is feasible for that BFER. The primary advantage of node protection is its enhanced protection quality compared to link protection. However, node protection also has certain drawbacks. It typically results in longer backup paths than link protection. In the context of tunnel-based BIER-FRR, node protection may lead to the transmission of a greater number of redundant packets over a link than with link protection. Furthermore, for LFA-based BIER-FRR, fewer BFERs may be protected using normal BIER-LFAs, necessitating the use of more remote or topology-independent BIER-LFAs, which are inherently more complex.
"

530	4.3.  Example
531
532	   In Figure 2, B1's primary path towards BFER B5 is B1-B6-B5.  Node
533	   protection for BFER B5 can be achieved only via the backup path
534	   B1-B2-B3-B4-B5.  Link protection for BFER 5 is achieved via the
535	   backup path B1-B2-B7-B6 and in addition via the backup path
536	   B1-B2-B3-B4-B5-B6.  The backup entries depend on the protection level
537	   and on the backup strategy.  Example BIFTs for link and node
538	   protection are given in Section 5.

[minor]
proposed rewrite:

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

540	5.  Backup Strategies
541
542	   The backup strategies determine the selection of the backup
543	   forwarding entries.  They have an impact on the backup BFR-NBR and on
544	   the backup action, and thereby on the backup path.  In the following,
545	   tunnel-based BIER-FRR and LFA-based BIER-FRR are presented.
546
547	5.1.  Tunnel-Based BIER-FRR
548
549	   The routing underlay may be able to forward packets towards their
550	   destinations despite an existing failure.  This may be achieved,
551	   e.g., due to FRR mechanisms in the routing underlay.  In that case,
552	   the primary BFR-NBR is not reachable via the primary action (Plain),
553	   but it may be reachable via a backup action (Tunnel).
554
555	   Tunnel-based BIER-FRR encapsulates BIER packets affected by a failure
556	   in the routing underlay to leverage its fast restoration capability.
557	   The affected BIER packets can be delivered towards their destinations
558	   as soon as the connectivity in the routing underlay is restored.  The
559	   appropriate backup forwarding entries in a BIFT for BIER-FRR depend
560	   on the desired protection level.

[minor]
proposed rewrite:

"
5. Backup Strategies

Backup strategies determine the selection of backup forwarding entries, influencing both the choice of the backup BFR-NBR and the backup action, and consequently, the backup path. The following sections present tunnel-based BIER-FRR and LFA-based BIER-FRR as potential strategies.

5.1. Tunnel-Based BIER-FRR

The routing underlay may possess the capability to forward packets to their destinations even in the presence of a failure, potentially due to FRR mechanisms within the routing underlay. In such scenarios, while the primary BFR-NBR may no longer be reachable via the primary action (Plain), 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.
"

562	5.1.1.  Tunnel-Based BIER-FRR with Link Protection
563
564	   With link protection, the backup BFR-NBRs equal the primary BFR-NBRs.
565	   If a primary BFR-NBR is directly connected to the BFR as a PLR, the
566	   corresponding backup forwarding action is Tunnel.  As a result, the
567	   BIER packets affected by a failure are tunneled over the routing
568	   underlay to their BFR-NBR instead of being sent directly as plain
569	   BIER packets to the BFR-NBR.  If a primary BFR-NBR is not directly
570	   connected to the BFR as a PLR (i.e., the implicit, primary action is
571	   Tunnel), the corresponding backup action is also Tunnel.  The backup
572	   F-BMs are the same as the primary F-BMs, which is in line with the
573	   computation of the backup F-BMs in Section 2.4.
573
575	       +------+----------+--------+-----------+---+-----------------+
576	       |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
577	       |      |          |        |           |   |  failure of     |
578	       +======+==========+========+===========+===+=================+
579	       |   2  | 0000110  |  B2    |  Tunnel   |   |  Link B1->B2    |
580	       +------+----------+--------+-----------+---+-----------------+
581	       |   3  | 0000110  |  B2    |  Tunnel   |   |  Link B1->B2    |
582	       +------+----------+--------+-----------+---+-----------------+
583	       |   4  | 1111000  |  B6    |  Tunnel   |   |  Link B1->B6    |
584	       +------+----------+--------+-----------+---+-----------------+
585	       |   5  | 1111000  |  B6    |  Tunnel   |   |  Link B1->B6    |
586	       +------+----------+--------+-----------+---+-----------------+
587	       |   6  | 1111000  |  B6    |  Tunnel   |   |  Link B1->B6    |
588	       +------+----------+--------+-----------+---+-----------------+
589	       |   7  | 1111000  |  B6    |  Tunnel   |   |  Link B1->B6    |
590	       +------+----------+--------+-----------+---+-----------------+
591
592	       Figure 7: B1's backup BIFT for tunnel-based BIER-FRR with link
593	                                protection.
594
595	   Figure 7 shows B1's backup BIFT for tunnel-based BIER-FRR with link
596	   protection for the BIER network example of Figure 2.  The backup BFR-
597	   NBRs and backup F-BMs in this backup BIFT are the same as the primary
598	   BFR-NBRs and primary F-BMs in the primary BIFT in Figure 4, but the
599	   backup actions in this backup BIFT are Tunnel while the primary
600	   actions in the primary BIFT are Plain (which are not shown, but
601	   implied).
602
603	   When B1 as a PLR detects failure of its link to B6, a BIER packet
604	   with bitstring 0100000 for B6 is tunneled by B1 towards B6 via the
605	   routing underlay.  The exact path of the backup tunnel depends on the
606	   routing underlay.  It may be B1-B2-B7-B6 or B1-B2-B3-B4-B5-B6.
607
608	   If a BIER packet is destined to {B2, B5, B7}, first an encapsulated
609	   packet copy is forwarded via link B1-B2 to backup BFR-NBR B6 with
610	   backup action Tunnel to deliver packet copies to BFER B5 and B7.
611	   Then, a non-encapsulated packet copy is forwarded via link B1-B2 to
612	   BFR-NBR B2 with primary action Plain to deliver a packet copy to BFER
613	   B2.  Thus, with tunnel-based BIER-FRR, a single redundant packet copy
614	   can occur in case of a failure because an encapsulated packet copy
615	   and a non-encapsulated packet copy are forwarded over the same link.
616	   This happens although BIER packets affected by failures are forwarded
617	   before BIER packets not affected by failures.
618
619	   A BIER packet with bitstring 1000000 for B7 is forwarded on the
620	   backup path B1-B2-B7-B6-B7 as it is first delivered to the backup
621	   BFR-NBR B6.  Thus, the backup path can be unnecessarily long.  This
622	   phenomenon is known from facility backup method in [RFC4090] which
623	   takes similar paths as tunnel-based BIER-FRR.

[minor]
proposed rewrite:

"
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 plain 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, consistent with the computation of backup F-BMs described in Section 2.4.

   +------+----------+--------+-----------+---+-----------------+
   |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
   |      |          |        |           |   |  failure of     |
   +======+==========+========+===========+===+=================+
   |   2  | 0000110  |  B2    |  Tunnel   |   |  Link B1->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    |
   +------+----------+--------+-----------+---+-----------------+
   
   Figure 7: B1's backup BIFT for tunnel-based BIER-FRR with link protection.

Figure 7 illustrates B1's backup BIFT for tunnel-based BIER-FRR with link protection in the BIER network example depicted in Figure 2. 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 shown in Figure 4. However, the backup actions in this backup BIFT are Tunnel, while the primary actions in the primary BIFT are Plain (which are not explicitly shown but implied).

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 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 action Plain to deliver a packet copy to BFER B2. Therefore, with tunnel-based BIER-FRR, 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.

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 [RFC4090], which employs paths analogous to those in tunnel-based BIER-FRR.
"

625	5.1.2.  Tunnel-Based BIER-FRR with Node Protection
626
627	   To determine the backup forwarding entries with node protection, a
628	   case analysis for the BFER to protect is needed.  If the BFER is the
629	   same as its primary BFR-NBR, node protection is not possible for that
630	   BFER.  Therefore, link protection is applied, i.e., the backup BFR-
631	   NBR is set to the primary BFR-NBR.  If that level of protection is
632	   not sufficient, egress protection in [I-D.chen-bier-egress-protect]
633	   may be applied.  Otherwise (i.e., the BFER is different from its
634	   primary BFR-NBR), the backup BFR-NBR is set to the primary BFR-NBR's
635	   primary BFR-NBR for that BFER, i.e., the backup BFR-NBR is a next
636	   next hop BFR.  In all cases, the backup action is Tunnel.  In the
637	   first case, the backup F-BM is set to all zeroes plus the bit enabled
638	   for the BFER to protect.  In the second case, the backup F-BM is
639	   computed in the way described in Section 2.4.
640
641	        +------+----------+--------+----------+---+-----------------+
642	        |BFR-id|  BF-BM   |BBFR-NBR|   BFA    |BEA|Comment: protects|
643	        |      |          |        |          |   |  failure of     |
644	        +======+==========+========+==========+===+=================+
645	        |   2  | 0000010  |   B2   |  Tunnel  |   |  Link B1->B2    |
646	        +------+----------+--------+----------+---+-----------------+
647	        |   3  | 0000100  |   B3   |  Tunnel  |   |  BFR-NBR B2     |
648	        +------+----------+--------+----------+---+-----------------+
649	        |   4  | 0011000  |   B5   |  Tunnel  |   |  BFR-NBR B6     |
650	        +------+----------+--------+----------+---+-----------------+
651	        |   5  | 0011000  |   B5   |  Tunnel  |   |  BFR-NBR B6     |
652	        +------+----------+--------+----------+---+-----------------+
653	        |   6  | 0100000  |   B6   |  Tunnel  |   |  Link B1->B6    |
654	        +------+----------+--------+----------+---+-----------------+
655	        |   7  | 1000000  |   B7   |  Tunnel  |   |  BFR-NBR B6     |
656	        +------+----------+--------+----------+---+-----------------+
657
658	       Figure 8: B1's backup BIFT for tunnel-based BIER-FRR with node
659	                                protection.
660
661	   Figure 8 shows B1's backup BIFT for tunnel-based BIER-FRR with node
662	   protection for the BIER network example in Figure 2.  BFERs B2 and B6
663	   are direct neighbors of B1.  To protect them, only link protection is
664	   applied as B1's primary BFR-NBR for them are those nodes themselves.
665	   According to the description above, only the bit for B2 is set in the
666	   backup F-BM of B2.  The same holds for B6.  For BFER B5, the backup
667	   BFR-NBR is B5 as it is B1's next next hop BFR towards B5.  Similarly,
668	   for BFER B7, the backup BFR-NBR is B7.  When B1 as a PLR detects the
669	   failure of its BFR-NBR B6, a BIER packet with bitstring 1010010 for
670	   {B2, B5, B7} is processed as follows.  An encapsulated copy of the
671	   packet is sent via tunnel B1-B2-B3-B4-B5, another encapsulated copy
672	   is sent via tunnel B1-B2-B7, and a non-encapsulated copy is sent via
673	   link B1-B2.  In this example, two redundant packets are sent on link
674	   B1-B2.  Thus, with node protection, more redundant packets copies may
675	   be sent than with link protection.
676
677	   Caveat: If the routing underlay does not provide node protection,
678	   tunnel-based BIER-FRR cannot provide node protection, either.  This
679	   is shown by the following example.  The underlay in the networking
680	   example of Figure 2 offers only link protection.  B6 fails and B1
681	   must forward a packet to B5.  According to the backup BIFT in
682	   Figure 8 the packet is tunneled towards B5 and the tunnel path
683	   B1-B2-B7-B6-B5 may be taken for this purpose by the underlay due to
684	   FRR with link protection.  However, B6 is also unreachable at B7 so
685	   that the packet is returned to B2 and the packet loops between B2 and
686	   B7.

[minor]
proposed rewrite:

"
To determine the backup forwarding entries for node protection, a case-by-case analysis of the BFER to be protected is required. If the BFER is the same as its primary BFR-NBR, node protection is not feasible for that BFER. In such cases, link protection is applied, meaning the backup BFR-NBR is set to the primary BFR-NBR. If this level of protection is deemed insufficient, egress protection as described in [I-D.chen-bier-egress-protect] may be applied. 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 all scenarios, the backup 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 Section 2.4

   +------+----------+--------+----------+---+-----------------+
   |BFR-id|  BF-BM   |BBFR-NBR|   BFA    |BEA|Comment: protects|
   |      |          |        |          |   |  failure of     |
   +======+==========+========+==========+===+=================+
   |   2  | 0000010  |   B2   |  Tunnel  |   |  Link B1->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     |
   +------+----------+--------+----------+---+-----------------+

   Figure 8: B1's backup BIFT for tunnel-based BIER-FRR with node protection.

Figure 8 illustrates B1's backup BIFT for tunnel-based BIER-FRR with node protection in the BIER network example provided in Figure 2. BFERs B2 and B6 are direct neighbors of B1. To protect them, only link protection is applied, as B1's primary BFR-NBR for these nodes is 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 Figure 2, 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 Figure 8, 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.
"

688	5.1.3.  Implementation Experience

690	   Tunnel-based BIER-FRR has been implemented in P4 for the software-
691	   switch bmv2 [MeLi20b] and the hardware switching ASIC Tofino
692	   [MeLi21].  Performance results have been provided.

[major]
This section is better placed in appendix and not be in the body of the document. 


694	5.2.  LFA-based BIER-FRR
694
696	   LFA-based BIER-FRR leverages alternate BFRs to deliver BIER packets
697	   to BFERs for which the primary BFR-NBR is unreachable.  It does not
698	   rely on any fast restoration/protection mechanisms in the underlay.
699	   First, some prerequisites for LFA-based BIER-FRR are clarified, BIER-
700	   LFAs are defined, and then link and node protection for LFA-based
701	   BIER-FRR are discussed using a single backup BIFT.
702
703	5.2.1.  Relation of BIER-LFAs to IP-LFAs and Prerequisites
704
705	   A loop-free alternate (LFA) for a specific destination is an
706	   alternate node to which a packet is sent if the primary next hop for
707	   this destination is not reachable.  This alternate node should be
708	   able to forward the packet without creating a forwarding loop.  LFAs
709	   have been defined for IP networks in [RFC5286], [RFC7490] and
710	   [I-D.ietf-rtgwg-segment-routing-ti-lfa].  We denote such LFAs as IP-
711	   LFAs.  BIER-LFAs are very similar to IP-LFAs, but a BIER-LFA node
712	   must be a BFR.  If only a subset of the nodes in the routing underlay
713	   are BFRs, some IP-LFAs in the routing underlay may not be usable as
714	   BIER-LFAs.  To compute BIER-LFAs, network topology and link cost
715	   information from the routing underlay are needed.  This is a
716	   difference to tunnel-based BIER-FRR where knowledge about the primary
717	   BIFTs of a PLR and its BFR-NBRs is sufficient.
718
719	   LFA-based BIER-FRR may reuse IP-LFAs in the following sense as BIER-
720	   LFAs.  If an IP-LFA node for the destination of a specific BFER is a
721	   BFR, it may be reused as backup BFR-NBR for that BFER together with
722	   the backup action that is applied for that IP-LFA on the IP layer.  A
723	   normal IP-LFA corresponds to backup action plain, a remote IP-LFA to
724	   Tunnel, and a TI-IP-LFA to Explicit.
725
726	5.2.2.  Definition of BIER-LFAs
727
728	   As for IP-LFAs, there are several, different types of BIER-LFAs:
729
730	   *  A BFR is a normal BIER-LFA for a specific BFER if it is directly
731	      connected to the PLR and
732
733	      1.  the BFER can be reached from it through the BIER domain
734	      2.  both the path from the PLR to it and the path from it to the
735	          BFER are disjoint with the primary path from the PLR to the
736	          primary BFR-NBR.  These paths
737
738	          -  may contain the primary BFR-NBR for link protection, and
739
740	          -  must not contain the primary BFR-NBR for node protection.
741
742	   *  A BFR is a remote BIER-LFA for a specific BFER if it is not
743	      directly connected to the PLR, if it can be reached via a tunnel
744	      from the PLR, and if it also satisfies the aforementioned
745	      conditions 1 and 2.
746
747	   *  A BFR is a TI-BIER-LFA for a specific BFER if it is not directly
748	      connected to the PLR, if it cannot be reached via a tunnel from
749	      the PLR, if it is reachable from the PLR via an explicit path
750	      (i.e., with the help of a SR header), and if it also satisfies the
751	      aforementioned conditions 1 and 2.
752
753	   For some BFERs, one or more normal BIER-LFAs are available at a
754	   specific PLR.  For other BFERs, only remote and TI-LFAs are
755	   available.  And there may be some BFERs, for which only TI-LFAs are
756	   available.
757
758	   The backup actions to reroute BIER packets depending on the BIER-LFA
759	   types are:
760
761	   *  For normal BIER-LFA: Plain
762
763	   *  For remote BIER-LFA: Tunnel
764
765	   *  For TI-BIER-LFA: Explicit
766
767	5.2.3.  Protection Coverage of BIER-LFA Types
768
769	   The protection coverage is the set of BFERs that can be protected
770	   with a desired protection level by a certain BIER-LFA type.  The
771	   BIER-LFA types have the following properties:
772
773	   *  Normal BIER-LFAs
774
775	      -  The protection coverage is the least because some or many BFERs
776	         cannot be protected with the desired protection level or even
777	         not at all.
778
779	      -  Redundant packet copies are avoided.
780
781	      -  No encapsulation overhead.
782
783	   *  Remote BIER-LFAs
784
785	      -  They increase the protection coverage of normal BIER-LFAs.
786
787	      -  Redundant packet copies may occur on a link similar to tunnel-
788	         based BIER-FRR.
789
790	      -  Same encapsulation overhead as with tunnel-based BIER-FRR.
791
792	   *  TI-BIER-LFAs
793
794	      -  They complement the protection coverage of normal and remote
795	         BIER-LFAs to 100%.
796
797	      -  Redundant packets may occur on a link similar to tunnel-based
798	         BIER-FRR.
799
800	      -  Same or similar encapsulation overhead as with tunnel-based
801	         BIER-FRR depending on the FRR mechanism in the routing
802	         underlay.

[minor]
proposed rewrite:

"
5.2. LFA-based BIER-FRR

LFA-based BIER-FRR leverages alternate BFRs to deliver BIER packets to BFERs for which the 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.

5.2.1. Relation of BIER-LFAs to IP-LFAs and Prerequisites

A 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 [RFC5286], [RFC7490], and [I-D.ietf-rtgwg-segment-routing-ti-lfa], 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 action Plain, a remote IP-LFA to Tunnel, and a TI-IP-LFA to Explicit.

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

  1. the BFER can be reached from it through the BIER domain.
  2. 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 some BFERs, one or more normal BIER-LFAs may be available at a specific PLR. For other BFERs, only remote or TI-BIER-LFAs may be available. There may also be BFERs for which only TI-BIER-LFAs are available.

The backup actions for rerouting BIER packets depending on the type of BIER-LFA are:

* For normal BIER-LFA: Plain
* For remote BIER-LFA: Tunnel
* For TI-BIER-LFA: Explicit

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

804	5.2.4.  Sets of Supported BIER-LFAs
805
806	   Normal BIER-LFAs are simplest, as they require neither tunneling nor
807	   explicit paths.  Remote BIER-LFAs are more powerful, but entail more
808	   header overhead and require more functionality from the PLR.  TI-
809	   BIER-LFAs are most complex as they require the use of explicit paths.
810	   When LFA-based BIER-FRR is utilized, the set of supported BIER-LFAs
811	   must be indicated.  The following options are available:
812
813	   *  Option 1: only normal BIER-LFAs are supported
814
815	   *  Option 2: normal and remote BIER-LFAs are supported
816
817	   *  Option 3: all BIER-LFA types are supported

[minor]
proposed rewrite:

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

819	5.2.5.  Link Protection
820
821	   With link protection, normal BIER-LFAs are preferred over remote LFAs
822	   and remote BIER-LFAs are preferred over TI-BIER-LFAs.  Depending on
823	   the set of supported BIER-LFAs, a BFER may not be protectable.
824
825	   Figure 5 illustrates B1's backup BIFT for LFA-based BIER-FRR with
826	   link protection in the networking example of Figure 2.
827
828	   If the link B1-B6 fails, B1 cannot reach the BFERs B4, B5, B6, and B7
829	   over their primary BFR-NBR.  Therefore, B1 sends their traffic via
830	   the backup BFR-NBR B2 together with the traffic for B2 and B3 as B2
831	   is their primary BFR-NBR.  As a consequence, the backup F-BM is
832	   1111110 in that case.  Likewise, if the link B1-B2 fails, B1 sends
833	   all traffic to B6, and the backup F-BM is 1111110 also in that case.
834
835	   B1 requires only normal BIER-LFAs to protect all BFERs.  This can be
836	   substantially different for other BFRs.  Figure 9 and Figure 10 show
837	   the backup BIFTs for B7 and B5 respectively.  BFR B7 requires one
838	   normal BIER-LFA, three remote BIER-LFAs, and two TI-BIER-LFAs to
839	   protect all BFERs.  And BFR B5 requires even one normal BIER-LFA, one
840	   remote BIER-LFA, and four TI-BIER-LFAs as backup BFR-NBRs.  Thus,
841	   depending on the set of supported BIER-LFAs, a BFER cannot be
842	   protected by BIER-FRR.
843
844	   We now assume B7 has a BIER packet with destinations {B1, B4, B5,
845	   B6}.  When link B7-B6 fails, the packet copy for B1 is sent to B2
846	   using forwarding action Plain, the packet copy to B4 is tunneled via
847	   B2 to B3, and the packet copies towards B5 and B6 are sent via
848	   explicit paths towards B4 and B1 respectively.  As these packet
849	   copies have different headers, they all need to be sent.  Hence, we
850	   observe three redundant copies.
851
852	       +------+----------+--------+-----------+---+-----------------+
853	       |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
854	       |      |          |        |           |   |  failure of     |
855	       +======+==========+========+===========+===+=================+
856	       |   1  | 0000111  |   B2   |  Plain    |   |  Link B7->B6    |
857	       +------+----------+--------+-----------+---+-----------------+
858	       |   2  | 0000110  |   B1   |  Tunnel   |   |  Link B1->B2    |
859	       +------+----------+--------+-----------+---+-----------------+
860	       |   3  | 0000110  |   B1   |  Tunnel   |   |  Link B1->B2    |
861	       +------+----------+--------+-----------+---+-----------------+
862	       |   4  | 0001000  |   B3   |  Tunnel   |   |  Link B1->B6    |
863	       +------+----------+--------+-----------+---+-----------------+
864	       |   5  | 0010000  |   B4   |  Explicit |   |  Link B1->B6    |
865	       +------+----------+--------+-----------+---+-----------------+
866	       |   6  | 0100000  |   B1   |  Explicit |   |  Link B1->B6    |
867	       +------+----------+--------+-----------+---+-----------------+
868
869	              Figure 9: B7's backup BIFT with link protection.
870
871	       +------+----------+--------+-----------+---+-----------------+
872	       |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
873	       |      |          |        |           |   |  failure of     |
874	       +======+==========+========+===========+===+=================+
875	       |   1  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
876	       +------+----------+--------+-----------+---+-----------------+
877	       |   2  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
878	       +------+----------+--------+-----------+---+-----------------+
879	       |   3  | 0000100  |   B4   |  Plain    |   |  Link B5->B6    |
880	       +------+----------+--------+-----------+---+-----------------+
881	       |   4  | 0001000  |   B3   |  Tunnel   |   |  Link B5->B4    |
882	       +------+----------+--------+-----------+---+-----------------+
883	       |   6  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
884	       +------+----------+--------+-----------+---+-----------------+
885	       |   7  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
886	       +------+----------+--------+-----------+---+-----------------+
887
888	             Figure 10: B5's backup BIFT with link protection.

[minor]
proposed rewrite:

"
In link protection, normal BIER-LFAs are prioritized over remote 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 all BFERs.

Figure 5 illustrates B1's backup BIFT for LFA-based BIER-FRR with link protection, using the network example provided in Figure 2.

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. Figures 9 and 10 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 forwarding action Plain, 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 headers, all of them must be transmitted, resulting in three redundant copies.

   +------+----------+--------+-----------+---+-----------------+
   |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
   |      |          |        |           |   |  failure of     |
   +======+==========+========+===========+===+=================+
   |   1  | 0000111  |   B2   |  Plain    |   |  Link B7->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    |
   +------+----------+--------+-----------+---+-----------------+

   Figure 9: B7's backup BIFT with link protection.

   +------+----------+--------+-----------+---+-----------------+
   |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
   |      |          |        |           |   |  failure of     |
   +======+==========+========+===========+===+=================+
   |   1  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   2  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   3  | 0000100  |   B4   |  Plain    |   |  Link B5->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   4  | 0001000  |   B3   |  Tunnel   |   |  Link B5->B4    |
   +------+----------+--------+-----------+---+-----------------+
   |   6  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
   +------+----------+--------+-----------+---+-----------------+
   |   7  | 1100011  |   B3   |  Explicit |   |  Link B5->B6    |
   +------+----------+--------+-----------+---+-----------------+

   Figure 10: B5's backup BIFT with link protection.
"

890	5.2.6.  Node Protection
891
892	   To determine the backup forwarding entries with node protection, a
893	   case analysis for the BFER to protect is needed again.  If the BFER
894	   is the same as its primary BFR-NBR, node protection is not possible
895	   for that BFER.  In this case, link protection is applied.  Otherwise,
896	   the BFER must be protected by a node-protecting BIER-LFA.  Thereby,
897	   normal BIER-LFAs are preferred over remote BIER-LFAs and remote BIER-
898	   LFAs are preferred over TI-BIER-LFAs.  Depending on the set of
899	   allowed BIER-LFAs, a BFER may not be protectable.
900
901	   Figure 11 illustrates B1's backup BIFT for the LFA-based BIER-FRR
902	   with node protection in the networking example of Figure 2.
903
904	       +------+----------+--------+-----------+---+-----------------+
905	       |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
906	       |      |          |        |           |   |  failure of     |
907	       +======+==========+========+===========+===+=================+
908	       |   2  | 1111010  |   B6   |  Plain    |   |  BFR-NBR B2     |
909	       +------+----------+--------+-----------+---+-----------------+
910	       |   3  | 0000100  |   B4   |  Tunnel   |   |  BFR-NBR B2     |
911	       +------+----------+--------+-----------+---+-----------------+
912	       |   4  | 0001000  |   B3   |  Tunnel   |   |  BFR-NBR B6     |
913	       +------+----------+--------+-----------+---+-----------------+
914	       |   5  | 0010000  |   B4   |  Explicit |   |  BFR-NBR B6     |
915	       +------+----------+--------+-----------+---+-----------------+
916	       |   6  | 1100100  |   B2   |  Plain    |   |  BFR-NBR B6     |
917	       +------+----------+--------+-----------+---+-----------------+
918	       |   7  | 1100100  |   B2   |  Plain    |   |  BFR-NBR B6     |
919	       +------+----------+--------+-----------+---+-----------------+
920
921	             Figure 11: B1's backup BIFT with node protection.
922
923	   As the primary BFR-NBR of B1 for BFER B6 is B6 itself, only link
924	   protection can be applied.  Therefore, B2 is used as normal, link-
925	   protection BIER-LFA to protect B6.  Likewise, the primary BFR-NBR of
926	   B1 for BFER B2 is B2, and therefore, B2 is protected with B6 as
927	   normal, link-protecting BIER-LFA.  BFER B7 is protected against the
928	   failure of node B6 with B2 as normal, node-protecting BIER-LFA as B2
929	   has a shortest path towards B7 that does not traverse B6.  The backup
930	   F-BMs for BFER 6 and BFER 7 are {B2, B6, B7} because if B6 is
931	   unreachable, the traffic for these BFERs is sent via link B1-B2 with
932	   forwarding action Plain.
933
934	   BFER B4 is not reachable through a normal LFA when BFR B6 fails.
935	   However, B3 is a remote, node-protecting BIER-LFA for BFER B4 because
936	   B3 has a shortest path towards B4, and B3 is reachable through a
937	   shortest path from B1, and the resulting backup path from B1 to B4
938	   does not traverse B6.  Likewise, B4 is a remote LFA for BFER B3 if
939	   BFR B2 fails.
940
941	   BFER B5 is neither reachable through a normal BIER-LFA nor through a
942	   remote BIER-LFA when BFR B6 fails.  However, B4 is a node-protecting
943	   TI-LFA for BFER B5 because B4 has a shortest path towards B5 that
944	   does not traverse B6.  Moreover, B4 is reachable through the explicit
945	   path B1-B2-B3-B4.

[minor]
proposed rewrite:

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

Figure 11 illustrates B1's backup BIFT for LFA-based BIER-FRR with node protection, using the network example provided in Figure 2.

   +------+----------+--------+-----------+---+-----------------+
   |BFR-id|  BF-BM   |BBFR-NBR|   BFA     |BEA|Comment: protects|
   |      |          |        |           |   |  failure of     |
   +======+==========+========+===========+===+=================+
   |   2  | 1111010  |   B6   |  Plain    |   |  BFR-NBR B2     |
   +------+----------+--------+-----------+---+-----------------+
   |   3  | 0000100  |   B4   |  Tunnel   |   |  BFR-NBR B2     |
   +------+----------+--------+-----------+---+-----------------+
   |   4  | 0001000  |   B3   |  Tunnel   |   |  BFR-NBR B6     |
   +------+----------+--------+-----------+---+-----------------+
   |   5  | 0010000  |   B4   |  Explicit |   |  BFR-NBR B6     |
   +------+----------+--------+-----------+---+-----------------+
   |   6  | 1100100  |   B2   |  Plain    |   |  BFR-NBR B6     |
   +------+----------+--------+-----------+---+-----------------+
   |   7  | 1100100  |   B2   |  Plain    |   |  BFR-NBR B6     |
   +------+----------+--------+-----------+---+-----------------+

   Figure 11: B1's backup BIFT with node protection.

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 forwarding action Plain 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-LFA for BFER B5, as B4 has a shortest path to B5 that does not traverse B6. Additionally, B4 is reachable through the explicit path B1-B2-B3-B4.
"

947	5.2.7.  Optimization Potential to Reduce Redundant BIER Packets in
948	        Failure Cases
949
950	   Redundant packets occur with LFA-based BIER-FRR if BIER packets are
951	   sent over a specific link in different forms.  These forms are
952	   *  plain BIER packets (plain primary transmission or reroute to
953	      normal BIER-LFA)
954
955	   *  BIER packets encapsulated to a specific BFR-NBR (tunneled primary
956	      transmission or reroute to remote BIER-LFA)
957
958	   *  BIER packets with an encoded explicit path (reroute to TI-LFA)
959
960	   When different remote LFAs are addressed, even multiple redundant
961	   packets can be caused through remote LFAs.  The same can happen with
962	   TI-LFAs.  Some redundant packets can be avoided if remote LFAs or TI-
963	   LFAs are chosen such that they can protect several BFERs and thereby
964	   avoid the need for another remote LFA or TI-LFA.  However, this may
965	   lead to longer backup paths.  This is a new, potential optimization
966	   objective for the choice of remote or TI-BIER-LFAs which does not
967	   exist for IP-FRR.  Its relevance may depend on the use case.
968
969	   We illustrate this optimization potential.  We consider LFA-based
970	   BIER-FRR with link protection for B7.  Its backup BIFT is given in
971	   Figure 9.  As observed in Section 5.2.5, B7 needs to send four copies
972	   to forward a packet to {B1, B4, B5, B6}.  If we choose the more
973	   complex TI-BIER-LFA B4 to protect BFER B4 instead of the remote BIER-
974	   LFA B3, then only two redundant copies need to be sent.

[minor]
proposed rewrite:

"
Redundant packets can occur with LFA-based BIER-FRR when BIER packets are transmitted over a specific link in different forms, including:

* Plain 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 LFAs are utilized, multiple redundant packets may be generated through remote LFAs. A similar situation can arise with TI-LFAs. However, some redundant packets can be mitigated if remote LFAs or TI-LFAs are selected such that they can protect multiple BFERs, thereby reducing the need for additional remote LFAs or TI-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 Figure 9. As noted in Section 5.2.5, 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.
"

976	6.  Comparison
977
978	   This section first discusses the difference of IP-LFAs for IP-FRR and
979	   BIER-LFAs for BIER-FRR.  Then it discusses advantages and
980	   disadvantages of tunnel-based and LFA-based BIER-FRR.
981
982	6.1.  Comparison of LFA-Based Protection for IP-FRR and BIER-FRR
983
984	   LFAs have been first proposed for IP networks.  They are simple in
985	   the sense that they do not require any tunneling overhead.  However,
986	   some destinations cannot be protected against some link failures and
987	   even more destinations cannot be protected against some node
988	   failures.  Therefore, remote LFAs (R-LFAs) have been defined to
989	   improve that coverage by tunneling the affected traffic to another
990	   node from where the traffic can reach the destination via normal
991	   forwarding.  Nevertheless, there may be still some destinations that
992	   cannot be protected against link or node failures.  Therefore,
993	   topology-independent LFAs (TI-LFAs) have been defined where affected
994	   traffic is tunneled via an explicit path (preferably using segment
995	   routing headers) to another node from where the traffic can reach its
996	   destination via normal IP forwarding.  With TI-LFAs, all destinations
997	   can be protected against any failures as long as connectivity exists.
998
999	   LFA-based BIER-FRR adopts the idea of LFAs.  It differs from IP-FRR
1000	   as the LFA target node, i.e., the node to which the traffic is
1001	   deviated, must be a BFR.  If an IP-LFA target is a BFR, it can be
1002	   utilized as a BIER-LFA; otherwise it cannot serve as BIER-LFA.  Thus,
1003	   if only some nodes of the underlay are BFRs, the BIER-LFAs will be
1004	   substantially different from IP-LFAs.  Moreover, this makes it more
1005	   difficult to find normal LFAs for which tunneling is not needed.
1006	   That means, LFA-based BIER-FRR is likely to require more remote LFAs
1007	   and TI-LFAs than IP-FRR under such conditions.

[minor]
proposed rewrite:

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

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

LFAs were initially proposed for IP networks. They are straightforward in that they do not require any tunneling overhead. However, certain destinations cannot be protected against specific link failures, and even more destinations may be unprotected 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 node 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 identify normal LFAs that do not require tunneling. As a result, LFA-based BIER-FRR is likely to require more remote LFAs and TI-LFAs than IP-FRR under such conditions.
"

1009	6.2.  Advantages and Disadvantages of Tunnel-Based BIER-FRR
1010
1011	6.2.1.  Advantages
1012
1013	   *  Computation of backup forwarding entries is very simple.  Only
1014	      primary BIFTs of a PLR and its BFR-NBRs are needed to compute the
1015	      backup forwarding entries.  Routing information from the routing
1016	      underlay is not needed.
1017
1018	   *  The forwarding action Explicit is not needed.  However, depending
1019	      on the underlay, explicit forwarding may be used to achieve FRR in
1020	      the underlay.
1021
1022	6.2.2.  Disadvantages
1023
1024	   *  It requires a FRR mechanism on the underlay.
1025
1026	   *  It is limited to the protection level of the underlay.  E.g., if
1027	      the underlay supports only link protection, tunnel-based BIER-FRR
1028	      cannot provide node protection.
1029
1030	   *  Redundant packet copies may occur in tunnel-based BIER-FRR.
1031
1032	   *  In case of node protection, backup paths may be extended more than
1033	      needed.
1034
1035	   *  Requires a tunneling header for any rerouting, which creates
1036	      header overhead.
1037
1038	6.3.  Advantages and Disadvantages of LFA-Based BIER-FRR
1039
1040	6.3.1.  Advantages
1041
1042	   *  Does not rely on any fast protection of the underlay.
1043
1044	   *  Can provide better protection on the BIER layer than on the IP
1045	      layer; this is possible if LFA-based BIER-FRR utilizes BIER-LFAs
1046	      with better protection level than LFA-based IP-FRR.  E.g., the
1047	      underlay may provide only FRR with link protection while BIER-FRR
1048	      may provide node protection for BIER traffic.
1049
1050	   *  Avoids header overhead for normal BIER-LFAs.
1051
1052	6.3.2.  Disadvantages
1053
1054	   *  Computation of backup forwarding entries requires routing
1055	      information from the underlay.
1056
1057	   *  Computation of backup forwarding entries more complex if some
1058	      nodes of the underlay are not BFRs.
1059
1060	   *  Need for forwarding action Tunnel to protect some BFERs, which
1061	      adds header overhead.
1062
1063	   *  Need for forwarding action Explicit to achieve full protection
1064	      coverage for some topologies; otherwise only partial protection
1065	      coverage.  This requires support for explicit paths, e.g., segment
1066	      routing.
1067
1068	   *  More remote and TI-LFAs needed than for IP-FRR if some nodes in
1069	      the routing underlay are not BFRs.
1070
1071	   *  Redundant packet copies may occur in LFA-based BIER-FRR (but it's
1072	      less than with tunnel-based BIER-FRR).

[minor]
proposed rewrite:

"
6.2. Advantages and Disadvantages of Tunnel-Based BIER-FRR

6.2.1. Advantages

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

6.2.2. Disadvantages

* It relies on the presence of a FRR mechanism in the underlay.
* It 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.
* In the case of node protection, backup paths may be unnecessarily extended.
* A tunneling header is required for any rerouting, resulting in additional header overhead.

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

6.3.1. Advantages

* It does not depend on any fast protection mechanisms in the underlay.
* 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.
* It avoids header overhead for normal BIER-LFAs.

6.3.2. 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.
* 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 and TI-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.
"

1074	7.  Security Considerations
1075
1076	   This document does not introduce any new security issues beyond those
1077	   discussed in BIER architecture [RFC8279].

[major]
The security section looks very compact. Is this really correct?
This work suggests to use tunnels and various flavours of LFA for example.
Do these not have securty considerations that impact BIER traffic?

for example have a look at some key LFA security considerations and reflect relevance when applied to BIER:

1. Spoofing and False Route Advertisements
* LFA/R-LFA/TI-LFA Dependencies on Routing Information:
  - LFAs depend on accurate routing information to determine alternate paths. If an attacker can inject false routing information (e.g., by spoofing link-state advertisements), it could cause the network to select suboptimal or malicious paths for LFAs.
  - R-LFA and TI-LFA also depend on accurate routing information, particularly for determining the tunneling paths or explicit paths. False route advertisements could mislead the network into using insecure or compromised paths.

2. Man-in-the-Middle (MitM) Attacks
* Use of Alternate Paths:
  - By rerouting traffic through alternate paths, especially those that traverse multiple hops (as in R-LFA and TI-LFA), the risk of MitM attacks increases if any of the intermediate routers on the alternate path are compromised.
  - TI-LFA, which uses explicit paths, might expose traffic to routers that were not originally in the primary path, potentially allowing for interception or alteration of the traffic.

3. Confidentiality and Integrity
* Traffic Encapsulation:
  - R-LFA and TI-LFA involve encapsulating traffic, which may expose it to vulnerabilities if the encapsulation mechanisms are not secure. For instance, if IPsec or another secure encapsulation method is not used, an attacker might be able to intercept or alter the traffic in transit.
* Protection of Explicit Paths:
  - TI-LFA relies on explicit paths that are typically defined using segment routing. If these paths are not properly protected, an attacker could manipulate the segment list to reroute traffic through malicious nodes.

4. Increased Attack Surface
* Extended Topology:
  - By introducing LFAs, R-LFAs, and TI-LFAs, the network increases its reliance on additional routers and links, thereby expanding the potential attack surface. Compromise of any router in these alternate paths could expose traffic to unauthorized access or disruption.

5. Complexity and Configuration Errors
* Misconfigurations:
  - The complexity of configuring LFAs, R-LFAs, and TI-LFAs increases the risk of misconfigurations, which could inadvertently create security vulnerabilities, such as routing loops or the selection of insecure paths.
* Overhead and Resource Exhaustion:
  - The additional overhead introduced by encapsulation in R-LFA and the use of segment routing in TI-LFA can be exploited by attackers to exhaust network resources, such as CPU and memory, on routers.

6. Trust Model
* Trust in Routing Infrastructure:
  - The security of LFA, R-LFA, and TI-LFA mechanisms relies heavily on the trustworthiness of the underlying routing infrastructure. If the control plane is compromised (e.g., through route poisoning), the alternate paths selected by these mechanisms could lead to traffic being routed through untrusted or compromised parts of the network.

7. Securing the Routing Protocols
* Use of Secure Routing Protocols:
  - To mitigate the risks associated with false route advertisements and MitM attacks, it is recommended to use secure routing protocols (e.g., OSPFv3 with IPsec, or ISIS HMAC-SHA256 ) that provide authentication and integrity protection for routing updates.

8. Monitoring and Detection
* Anomaly Detection:
  - Implementing monitoring and anomaly detection mechanisms can help identify when traffic is being rerouted in unexpected ways, which could indicate a security issue with LFA, R-LFA, or TI-LFA mechanisms.




Brgds,
Gunter Van de Velde
Shepherding AD