On 25/08/2025 17:06, Mahesh Jethanandani wrote:
Hi Gorry,
Thanks for reviewing the document.
Hi thanks for getting back promptly to me!
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.
GF: I admit that I'm nervous of any hint that a loss count ought to be
zero for an operational path, and I don't see that, but I also don't see
anything that might hint that there are multiple ways that loss can
happen and some loss might be normal.
### 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.
GF: Thanks
### 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]
Best wishes,
Gorry
