BIER Fast Reroute (BIER-FRR)
draft-ietf-bier-frr-09

Thank you for a readable document. I read this from the perspective of a transport protocol, and have no transport-related comments.

Thanks to the authors and the WG for this document. 

Please find below some comments provided inline in the idnits output of v08 of the document.

122	   derived from a routing underlay or set by a controller.  In case of a
123	   persistent link or node failure, BIER traffic may not be delivered
124	   until the BIFT has been updated based on the reconverged routing
125	   underlay or by the controller.

<minor> Could you clarify what is meant by persistent here? Isn't this the
case for any link failure and especially so for a node failure (even if the
node would just reload)


166	      recalculation of the BIFT.  When the routing underlay utilizes FRR
167	      mechanisms, its forwarding capabilities are restored well before
168	      reconvergence is completed.  To benefit from the rapid restoration

<minor> perhaps s/reconvergence/control plane reconvergence 

172	   *  LFA-based BIER-FRR: This approach reroutes BIER traffic to
173	      alternative neighbors in the event of a failure.  It applies the
174	      principles of IP-FRR, requiring that LFAs are also BFRs.  Normal
175	      BIER-LFAs can be reached without tunneling, remote BIER-LFAs

<major> Please provide a reference or explanation of "normal BIER-LFAs". Did
you mean RFC5286? Same goes for the other types - please provide references

563	   NBR itself.  Consequently, the backup path with link protection
564	   cannot protect against the failure of the primary BFR-NBR..

<nit> Please remove extra "." I saw a few other similar instances in the document

770	   with the backup action applied for that IP-LFA at the IP layer.  A
771	   normal IP-LFA corresponds to the backup action Plain, a remote IP-LFA
772	   to Tunnel, and a TI-IP-LFA to Explicit.

<minor> Is that IP-TI-LFA ? Same Q for TI-BIER-LFA.

840	   *  TI-BIER-LFAs

842	      -  They complement the protection coverage of normal and remote
843	         BIER-LFAs to achieve 100% coverage.

<major> Isn't that 100% theoretical? Practically, there are limits of platform
and implementations. Also, all routers should be BFRs.


875	6.2.5.  Link Protection

877	   In the following, LFA-based BIER-FRR with link protection is

<nit> In the following ? ... perhaps "In this subsection," ?

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

<major> References to respective RFCs related to different types of LFA/FRR
unicast mechanisms would be helpful in this section as well.

<EoRv08>

Two minor observations: 

There appear to be a few superfluous references in this document. Please review and see whether there's additional text required or references that can be dropped:

- RFC2119 boilerplate is present and RFC2119 is referenced, but there don't appear to be any of the referenced terms present in the document.
- I-D.chen-bier-egress-protect is in the references, but not used in the text.

In 3.3, a space is missing: "[RFC5880]session" => "[RFC5880] session"

Hi Huaimo, Mike, Steffen, Michael, Aijun, and Gyan,

Thank you for the effort put into this specification. 

Please find some comments below:

# Main comments

## Lack of Operations considerations

The analysis can be strengthened by analyzing the deployment/ops implications of the options discussed in the spec. I noted that there are very few deployment pre-requisites (e.g., 6.2.1), though.

Also, some of the analyzed approach have implications on forwarding path stretch that is worth discussed vs. service objectives.

See rfc8279#section-7 for how this is handled for the base BIER spec.

## Leverage existing frameworks/discussions

For example, I was expecting a discussion about which matters from RFC7916 can be leveraged. 

Also, have a discussion whether the proposed approaches are immune against micro loops (or at least call guards, if any); see for example RFC8333. Such discussion is also meant to back early claims in the document such as “minimizing packet loss and service disruption”.

# Misc.

## Routing underly 

Please cite rfc8279#section-4.1 early in the document

## Encap over the routing underlay

Seems to always assume one single underly, while the base spec has this right:

   If multiple routing underlays are used in a single BIER domain, each
   BIER sub-domain MUST be associated with a single routing underlay
   (though multiple sub-domains may be associated with the same routing
   underlay).

## There are many controllers in networks

Please consider s/the controller/a controller, through the doc

## Deployment-specific

OLD:
   that BIER often carries multicast traffic with real-time
             ^^^^^^^^^^^^
   requirements, there is a particular need to protect BIER traffic
   against prolonged outages following failures.

NEW:
   that BIER may carry multicast traffic with real-time
   requirements, there is a particular need to protect BIER traffic
   against prolonged outages following failures.

## IP-FRR/”Normal” BIER-LFA

CURRENT:
      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

### Please cite an authoritative reference for I-FRR

### What is meant by “Normal BIER-LFAs”?

## Network layer

CURRENT:
   A BFR-NBR is considered directly connected if it is a next-hop at the
   network layer,

There is no such layer in the base spec. Please use consistent concepts.

## Packets are forwarded

OLD: that the packet is not routed through

NEW: that the packet is not forwarded through

## One or multiple backups

CURRENT:
   *  Backup Forwarding Bit Mask (BF-BM)

   *  Backup BFR Neighbor (BBFR-NBR)

There is only one backup? Or multiple entries can be used for multiple backups? How this is expected to work?

## BEA flag

CURRENT:
  The BEA flag indicates whether the backup forwarding
   entry is currently active.   

How is this set? Can this be managed by a controller such the one mentioned in the introduction?

## Derived? 

CURRENT:
   The primary forwarding action is not explicitly stated in the BIFT as
   it is derived from the BFR-NBR.   

What does that mean?

## Desired level

CURRENT:
   The values
   for the BBFR-NBR and the BFA depend on the desired level of
   protection and the chosen backup strategy.  

How these are supplied to an implementation?

## BFD Extension

CURRENT:
   If
   the primary BFR-NBR is indirectly connected, a Bidirectional
   Forwarding Detection (BFD) [RFC5880] session between the BFR as PLR
   and the BFR-NBR may be used to monitor its reachability.

Do we need draft-ietf-bier-bfd or only the base BFD is sufficient here?

## Figures are actually tables through the doc.

## Not sure what is the value of Section 5? Maybe point to similar discussion in, e.g., Overview and Principles of Internet Traffic Engineering (RFC 9522).

Cheers,
Med