Hi Gorry, Thanks for reviewing the document.
> On Aug 25, 2025, at 8:31 AM, Gorry Fairhurst via Datatracker > <[email protected]> wrote: > > Gorry Fairhurst has entered the following ballot position for > draft-ietf-bfd-stability-19: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-stability/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this I-D on the about the operation of BFD. > > I have two concerns with the way in which performance is presented, these > are non-blocking comments, because they do not seek to change the protocol, > but even-so I do hope they are helpful in finalizing the text: > > ### Loss > Some services might require very tight controls on loss, but in general > Internet transports can be designed to be robust to occassional loss. > I am concerned that the current text might make it seem like loss-less > delivery was a goal, rather than seeing losss as a potential indication > of performance issues. This is important when we might expect to > see greater use of methods such as AQM that use loss to signal congestion. The document says the following in multiple places: In Abstract: "Specifically, it describes a mechanism for the detection of BFD packet loss.” (emphasis from me). The in the Introduction it says: "Noting the other missed packets provides a valuable indicator of systemic issues or a deteriorating network that may warrant preventive action.” and "This document proposes an experimental mechanism to detect lost packets in a BFD session in addition to the datapath fault detection mechanisms of BFD.” We do say in the Introduction that: "In order to prevent significant data loss due to a datapath failure, BFD session detection time as defined in BFD [RFC5880] is set to the smallest feasible value.” but even there we do not propose loss-less delivery. Could you point to text that gives the impression that loss-less delivery is the goal. > > ### Out-of-Order Metrics > I do have a concern that the optional support for out-of-order delivery > may not be the most useful service metric, given that several IETF > technologies have been developed that are robust to small levels > of re-ordering, and hence strict comparison of increasing sequence numbers > could make BFD more fragile than required by the transport layer (albeit > the sort of re-ordering here might be very small (e.g., one reordering event). Out-of-order delivery or a small packet loss is an indication of the problems in the network or the stability of a session. It is not meant to be an exact count of loss. That is why the draft suggests that other OAM protocols such as CFM and those defined in RFC6374 be used to further isolate losses. In addition, for links such as LAG, it does suggest that implementations MAY provide mechanisms where out-of-order packets are not considered lost packets. But you point is taken. We can further clarify how we are detecting loss. > > ### TSV-ART Review > Please also note the TSV-ART and respond to the review provided by Mirja in: > https://datatracker.ietf.org/doc/review-ietf-bfd-stability-19-tsvart-lc-kuehlewind-2025-08-11/ > and please respond to the topics identified in this review. Yes, we are working on responding to the TSV-ART review. Thanks. > > #### In addition, it would seem helpful to provide a little discussion of the > BFD receiver procedures and a reference to RFC 5880 section 6.8.1. > > > Mahesh Jethanandani [email protected]
