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"? 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/ 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). 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? 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]. " 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? 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? Kind Regards, Gunter Van de Velde RTG Area Director
