I am an assigned INT directorate reviewer for draft-ietf-bier-frr. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/

From a multicast perspective, this draft has several major issues that should be addressed. If I were on the IESG, I would ballot DISCUSS.

1. The abstract of the draft says that it "describes a mechanism for Fast Reroute (FRR) in Bit Index Explicit Replication (BIER) networks", but it actually describes several mechanisms, does not provide guidance on when each mechanism should be used, and does not specify if/how these multiple mechanisms inter-operate.

2. It is unclear why the draft has an Intended Status of Informational given that the BIER specification is Experimental. The draft also contains the 2119/8174 keyword boilerplate but contains no instances of capitalized keywords. I would expect a draft like this to leverage keywords to ensure inter-operability.

3. The Introduction contains the statement "BIER packets are forwarded without an outer IP header." In some instances, this is true, but BIER also works natively in IPv4 networks and in IPv6 networks (https://www.ietf.org/archive/id/draft-ietf-bier-bierin6-09.html). Given that, the draft is incomplete. Since BIER can work natively, it can actually leverage the IP-FRR functionality within a network. If there is a document looking at FRR for BIER, I think it needs to start with a proper assessment of how IP-FRR benefits BIER and where there may be gaps in IP-FRR functionality for BIER.

4. I am a bit perplexed by the definition of Tunnel-based BIER-FRR. It states that it leverages the routing underlay for FRR without doing any sort of description of the gaps that exist. If the underlay has an FRR capability, how much is applicable to BIER? That analysis would be beneficial in order to understand if a BIER-specific capability is needed.

5. Can you describe the deployment model where LFA-based BIER-FRR will be beneficial? Given the dependence on the routing underlay, when would this BIER-specific function be needed?

6. The statement "BIER-FRR has a significant advantage compared to state-based forwarding" is misleading. Why is the comparison being made to legacy IP multicast forwarding rather than to BIER and BIER + IP-FRR? BIER eliminated the need for per-node, per-group forwarding state. That should be the starting point for any comparisons.

7. Sections 4-7 are woefully incomplete. They describe capabilities and make performance comparisons on anecdotal, toy topologies. It is a disservice to implementers and operators to assume that they can extrapolate correct behaviors and configurations without concrete specifications.