Ketan, Addressing a subset of your points:
> On May 15, 2025, at 7:05 AM, Ketan Talaulikar <[email protected]> wrote: > > 150 5. NULL Auth Type > > <question> Why is a null auth type, or even a sequence number necessary for > BFD > packet loss calculation? Is it not OK to expect that the other endpoint is > going to send X number of packets every interval? And if we don't get those X > packets at every interval, then we have a packet loss? Perhaps I am missing > something obvious and if so, it would be good to capture the rationale that > really needs these sequence numbers for this measurement. Minimally, BFD jitters its timers. This means you can best probabilistically guess how many packets are being sent over a given interval. The desire here is to know that when a packet is transmitted, it didn't make it through. Some things such as multipath or packet queue infrastructure can perturb those things, including out of order delivery. To know that a specific transmitted packet has not been delivered, you have to identify it. > > 179 Auth Key ID: The authentication key ID in use for this packet. Must > 180 be set to zero and ignored on receipt. > > <minor> s/must/MUST > > 216 6.1. Loss Measurement > > 218 Loss measurement counts the number of BFD control packets missed at > 219 the receiver during any Detection Time period. The loss is detected > 220 by comparing the Sequence Number field in successive BFD control > 221 packets. The Sequence Number in each successive control packet > 222 generated on a BFD session by the transmitter is incremented by one. > 223 This loss count can then be exposed using the YANG module defined in > 224 the subsequent section. > > <major> Packets may be reordered and arrive with different delays. Let us say > that the > packet that was supposed to arrive in interval I were delayed to arrive in > interval > I+1. i.e., we get one extra packet in the interval I+1. This does not indicate > a packet loss in interval I, but the procedure above seems to log it as a > packet loss? See section 6.2. The desire of the WG over the original development of the draft was to document the easy procedures first. > > 226 The first BFD authentication section with a non-zero sequence number, > 227 in a valid BFD control packet, processed by the receiver is used for > 228 bootstrapping the logic. > > <major> Is the loss counter reset when the BFD session goes down? See the definition of "lost-packet-count" in the YANG module. "without bringing the session down". A reset of the counter is appropriate here. Some implementations may choose to preserve the value across resets for a configured session. There is unfortunately mixed use cases in terms of counter philosophy among IETF management folk. Many of the old timers prefer that counters are NEVER reset. That said, some clarification text may be appropriate for the expected default. > Is there a > notion of time period that is tracked/reported here? Is there a notion of a > percentage of BFD packets lost that is being reported? How useful is it to > simply report the lost packet count without any of these other contexts? Exactly as useful as other scalar values in every other management mechanism IETF has done, including historically MIBs. The expected operational model is either poll or push wherein the sampling interval for the poll or push provide the sense of loss over the observed time window. This is normal. > Looking at the model, the history of this data for the previous uptime is also > not being tracked. Have these aspects been considered by the WG? Somewhat typical for these data models, the scalars on their own aren't fully sufficient. Tracking the state of the session is typical, and the deltas in the observed lost packets are relevant across samples for the observed sample time, but only when the session in the Up state. This typical methodology is why IETF management folk prefer to not to reset the counters. The lingering detail tends to be whether there's a discontinuity indication if the system is reset. IETF hasn't provided a generalized mechanism for these sort of things that I'm aware of in YANG. For the lost packet counters in question, the session-statistics in the RFC 9314 module provides the usual generalized sense. Since this document's module augments that tree, it inherits that sense of continuity. > > 239 Implementations MAY provide mechanisms wherein all expected packets > 240 received across an expected interval but delivered out of order are > 241 not considered lost packets. > > <major> Why is this not a MUST? How is it ok to do incorrect and inaccurate > reporting of BFD packet loss? Please see my previous comment. Implementations and opeators may wish to reflect out of order delivery as service impacting. > > 243 7. Stability YANG Module > > <question> I am not an IETF YANG expert. I would like to check if there are > any issues with an experimental RFC augmenting a standards track YANG model. See your ops AD. > > 652 When the NULL Authentication type is used for BFD Stability purposes, > 653 maliciously injected packets that do not reset the BFD session can > 654 resemble high packet loss. Sessions such as, multi-hop routed paths, > 655 tunnels without authentication, or MPLS LSP, therefore, have security > 656 guarantees that are identical to situations where BFD is run without > 657 authentication. > > <minor> How about someone could manipulate the sequence numbers and give a > wrong idea of packet loss? Possibly raise false alarms? And thus "can resemble high packet loss". -- Jeff
