Hi Gunter, Thanks for your review comments. Please see inline.
> > On Sep 18, 2025, at 1:10 PM, Gunter Van de Velde via Datatracker > <[email protected]> wrote: > > Gunter Van de Velde 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: > ---------------------------------------------------------------------- > > # Gunter Van de Velde, RTG AD, comments for draft-ietf-bfd-stability-19 > > # The line numbers used are rendered from IETF idnits tool: > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bfd-stability-19.txt > > # for your convenience, please find some non-blocking COMMENTS > > # Appendix A explains the reasoning for Experimental assignation well and is > according my understanding fully in line with the procedure specified in > section 4.2.1 of RFC2026 (The Internet Standards Process -- Revision > 3)(https://datatracker.ietf.org/doc/html/rfc2026#section-4.2.1) > > # in general i found this a well written and easy to read document. Many > thanks > for writing this text. > > # comments > # ======== > > 138 Bidirectional Forwarding Detection, as defined in BFD [RFC5880] > 139 cannot detect any BFD packet loss if the loss does not last for the > 140 Detection Time. This document proposes a method to detect dropped > 141 packets on the receiver. For example, if the receiver receives BFD > 142 control packet k at time t but receives packet k+3 at time t+10ms, > 143 and never receives packet k+1 and/or k+2, then it has experienced a > 144 packet loss. > > GV> Maybe a name for such packet loss could be "Silent BFD Packet Loss"? We can use the name if there is frequent reuse of such packets. > > 146 This proposal enables BFD implementations to generate diagnostic > 147 information on the health of each BFD session that could be used to > 148 preempt a failure on a datapath that BFD was monitoring by allowing > 149 time for a corrective action to be taken. > > GV> s/preempt/preempt probability of/ Ok. > > 164 The NULL Authentication Type, defined in this document, can be used > 165 to provide a meticulously increasing sequence number for stability > 166 measurement. It provides none of the protections desired for > 167 authentication and is used only to provide BFD stability services > to > 168 BFD sessions that otherwise have no authentication in use. > > GV> similar as some others i got triggered by the word 'meticulously'. > Maybe use “strictly increasing” (most operator- and implementer-friendly) or > “monotonically increasing” (if you want mathematical precision). The term ‘meticulously’ has been introduced in RFC 5880. We can probably add a reference to the document rather than coming up with a new term or definition. > > 186 Auth Type: The Authentication Type, which in this case is TBD > (NULL, > 187 to be assigned by IANA, with a suggested value of 6). > > GV> if the technology is not implemented and there is no implementation > planned, then why suggest a a value to IANA? maybe just leave it up to them to > decide what is best for the tooling? There are two questions here. The question of “why publish if no plan to experiment”, and the question of IANA assignment to do the experiment. As the shepherd for this document has already stated, the question of publishing was discussed with some of the Routing ADs. Some of vendors do not want to implement technology unless they see an RFC, even when it is experimental. With the work done on the document, it was prudent to publish the document to allow those (experimental) implementations rather than to abandon the document at this stage. > > 174 0 1 2 3 > 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > 1 > 176 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 177 | Auth Type | Auth Len | Auth Key ID | Reserved > | > 178 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 179 | Sequence Number > | > 180 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 181 > 182 Figure 1: NULL Auth Type > 183 > 184 where: > 185 > 186 Auth Type: The Authentication Type, which in this case is TBD > (NULL, > 187 to be assigned by IANA, with a suggested value of 6). > 188 > 189 Auth Len: The length of the NULL Auth Type, in bytes; i.e., 8 bytes > 190 > 191 Auth Key ID: The authentication key ID in use for this packet. > MUST > 192 be set to zero and ignored on receipt. > 193 > 194 Reserved: This byte MUST be set to zero on transmit and ignored on > 195 receipt. > 196 > 197 Sequence Number: The sequence number for this packet. This value > is > 198 incremented for each successive packet transmitted for a session. > 199 Implementations will use sequence numbers (bfd.XmitAuthSeq) as > 200 defined in BFD [RFC5880]. > > GV> When the length of the fields is not described in the text, then the > figure > becomes normative. It has caused for confusions in teh past. It may better to > explicit mention the lengths: > > " > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Auth Type | Auth Len | Auth Key ID | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: NULL Auth Type > > The fields are defined as follows: > > Auth Type (8 bits): The Authentication Type. For the NULL Authentication Type, > the value is TBD (to be assigned by IANA, with a suggested value of 6). > > Auth Len (8 bits): Length of the NULL Authentication Type field, in octets. > The > value for this field is 8. > > Auth Key ID (8 bits): Authentication Key Identifier. This field MUST be set to > zero on transmission and MUST be ignored on receipt. > > Reserved (8 bits): This field MUST be set to zero on transmission and MUST be > ignored on receipt. > > Sequence Number (32 bits): Sequence number for the packet. This value is > incremented for each successive packet transmitted for a session. > Implementations MUST use sequence numbers (bfd.XmitAuthSeq) as defined in > [RFC5880]. " Ok. > > 228 6.1. Loss Measurement > > 230 Loss measurement counts the number of BFD control packets missed at > 231 the receiver during any Detection Time period. The loss is > detected > 232 by comparing the Sequence Number field in successive BFD control > 233 packets. The Sequence Number in each successive control packet > 234 generated on a BFD session by the transmitter is incremented by > one. > 235 This loss count can then be exposed using the YANG module defined > in > 236 the subsequent section. See discussion on Out of Order Packets > 237 (Section 6.2) later in the document. > > GV> What is a "Detection Time Period"? Is that something the operator needs to > provision? I did a searh in the document for "Detection Time period" but found > no definition on what it exactly means. COuld some context added about this? Sure. We can add a reference to Section 6.8.4 of RFC 5880. > > GV> I assume tha the loss here is an absolute discrete number, and not a loss > in bfd "drops per second" or so. has "Silent BFD Packet Loss" per time unit > been considered? It is a number. Thanks. > > Kind Regards, > Gunter Van de Velde > RTG Area Director > > >
