Hello Authors/WG, Thanks for the work put into this document. It has been in the works for a long time in an on/off mode. There is some more work needed before it can be taken up for IESG evaluation.
I would like to share my review of the v18 of this document. General Comment/Suggestion: This is about the contents of this document and its relationship with draft-ietf-bfd-optimizing-authentication and draft-ietf-bfd-secure-sequence-numbers. I believe this document does not depend on those other two, at least not normatively as indicated today. This proposal is self sufficient with the new null auth type and the two existing BFD auth types that use meticulous incrementing sequence numbers. As such, for smooth progression of this work, I would strongly recommend removing all references to those drafts and the ISAAC-based auth types or the Optimized Auth from this document. The draft-ietf-bfd-secure-sequence-numbers that actually specifies the two ISAAC-based auth types can instead refer to the draft-ietf-bfd-stability to indicate that those new auth types are suitable for use for measuring BFD packet loss. This way, this document becomes independent of the other two for its further processing. Please find below my comments in the idnits output of v18 and look for <EoRv18> at the very end of the review. If you don't see that, then likely the email has been truncated by your email client and you should look at the BFD WG email archive for the full version. Thanks, Ketan 14 BFD Stability 15 draft-ietf-bfd-stability-18 17 Abstract 19 This document describes extensions to the Bidirectional Forwarding 20 Detection (BFD) protocol to measure BFD stability. Specifically, it 21 describes a mechanism for detection of BFD packet loss. <major> The title/name of "BFD Stability" is misleading to me. It gives an impression of how stable is the BFD session, as in - is it flapping a lot or is staying up and stable for a long interval? Why not call this BFD Packet Loss Monitoring ... or something like that which is a simple term and yet perhaps gives the true picture of what this feature is about? 98 This document does not propose any BFD extension to measure data 99 traffic loss or delay on a link or tunnel and the scope is limited to 100 BFD packets. <major> Please provide some text for justification for the experimental status - something on similar lines as the other two documents will work just as well. 120 The reader is expected to be familiar with the BFD [RFC5880], 121 Optimizing BFD Authentication 122 [I-D.ietf-bfd-optimizing-authentication] and Meticulous Keyed ISAAC 123 for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers]. <major> I see no reason for the above two references or dependencies in this document. They seem unnecessary to me. What is the normative (must have) dependency that I am missing? And why is even an informative reference really necessary? 139 In a faulty datapath scenario, an operator can use BFD health 140 information to trigger delay and loss measurement OAM protocol 141 (Connectivity Fault Management (CFM) or Loss Measurement (LM)-Delay 142 Measurement (DM)) to further isolate the issue. <minor> Please provide informative references for the CFM and DM technologies 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. 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? 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? 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? 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? 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. 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. 599 9. Security Consideration 601 9.1. YANG Security Considerations <minor> Please reorder the sections. I know some of the authors are YANG champs, but let us not put the cart before the horse :-) 626 addition, and as stated in Out of Order Packets (Section 6.2), on 627 links such as LAG or ECMP, there is a possibility of packets being 628 delivered out of order. A strict comparison of increasing sequence 629 numbers may result in classifying those out of order packets as 630 packet loss. <minor> Does this text blob not belong to the Null Auth or a separate BFD Packet loss monitoring sub-section? 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? <EoRv18>
