Hello Jeff, Thanks for your quick reply.
There is no urgency to reply to all my points, else I would have submitted a PR ;-) See below for EVY> Regards -éric From: Jeffrey Haas <[email protected]> Date: Wednesday, 14 August 2024 at 14:35 To: Eric Vyncke (evyncke) <[email protected]> Cc: [email protected] <[email protected]>, John Scudder <[email protected]>, [email protected] <[email protected]>, Reshad Rahman <[email protected]> Subject: Re: Alternate AD review of draft-ietf-bfd-large-packets-11 Éric, I'm deep in the last stages of getting some important day-job stuff out the door, so the edits may linger for a little bit. But let me at least answer the questions portion. Note that this draft's text is checked into github as noted in the datatracker. Many of your edits could have avoided the need for "go do this" and instead simply have been a pull request. :-) On Aug 14, 2024, at 7:58 AM, Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> wrote: Dear BFD, dear authors, To lighten John Scudder’s workload, I will be the alternate responsible AD for draft-ietf-bfd-large-packets. As I am an INT AD, please bear with me if I state something wrong about BFD ;-) Before proceeding with the publication process, I usually do my AD review before starting the IETF Last Call and *I request either a reply or an action (revised I-D) for all the points below* (some of them are nits); the only goal is to ease the IESG evaluation later. Let’s work together to get this I-D published (and BTW, I like the idea and the technique) Regards -éric # shepherd write-up It contains `we will discuss further at the next IETF`, but it is unclear which IETF meeting ;) and if it was IETF-120, then what was the outcome of the discussion ? The answer to Question 11 should also have a justification of the intended status, e.g., ‘this document specifies a protocol that need to be interoperable’, ‘this I-D extends a proposed standards RFC’ or something similar # Abstract Please also state that a YANG module is also specified. `This document discusses thoughts` does not fit the ‘proposed standard’ intended status. Let’s use “This document specifies” # Section 1 `Previous proposals ([I-D.haas-xiao-bfd-echo-path-mtu<https://datatracker.ietf.org/doc/html/draft-haas-xiao-bfd-echo-path-mtu-01>]) have been made for testing Path MTU for such directly connected systems. However, in the case of multi-hop BFD [RFC5883<https://www.rfc-editor.org/info/rfc5883>], this guarantee does not hold.` this will seem a little weird when this I-D is published. It this part useful or required ? s/i.e./i.e.,/ possibly in other places as well and also applies to ‘e.g.’, which should be followed by a comma. s/certain minimum criteria/certain minimum criterion/ # Section 3 Suggest adding a reference (including the section) to `new BFD variable` Add the units (octet I guess) for bfd.PaddedPduSize Perversely, I don't think the module is served by noting "octets". Line cards forward bytes these days as units. :-) EVY> octets or bytes, I do not mind too much but let’s specify the units. # Section 4.1 Be specific on “receiving implementation” in `the implementation would follow normal BFD procedures` # Section 4.2 If only the largest MTU is probed and fails, then why not also trying smaller MTU rather than being blind about the MTU ? This behavior is consistent with section 4.4 but still a little weird to my eyes. It's inconsistent with deployed BFD behavior. When you have multiple clients, you go for the most restrictive set of parameters. EVY> did you mean “inconsistent” or “consistent” above ? EVY> does it mean that if the largest-MTU client fails, then all clients fail ? I.e., the link will be declared as down ? This seems quite drastic to me. # Section 4.5 References to LAG & ECMP will be welcome. ECMP is a RFC Editor well known keyword so I suspect we can skip that one. LAG is not. We can certainly sprinkle in the usual IEEE reference, but I don't think it helps clarity. EVY> ack on ECMP/LAG but, while it may not help clarity (by adding more words), it is good for completeness. More generally, I do not understand why this section is relevant to Large Packet BFD, i.e., it seels applicable to most BFD techniques. So why having it in this I-D ? This comes from list discussion. Yes, it's generic. Addressing it in some BFD draft generically would have been nicer. Having it in this document, in particular, has a bit of usefulness because it's discussing unexpected traffic loss across links - in this case due to MTU issues. EVY> the shepherd’s write-up also mentions this discussion, and indeed it has a “(small) bit of usefulness” in this document. If authors/WG want to keep it, then OK. s/Mis-configuration/Misconfiguration/ # Section 5.1 s/LAG and MPLS/LAG, and MPLS/ # Section 5.2 Why are there double quotes around rt in `prefix "rt";` and not for other prefixes ? Should there be a reference to RFC XXXX in `feature padding` ? `padded-pdu-size` be consistent by using either octet or byte. Unsure whether `The maximum padded PDU size may be limited by the supported interface MTU of the system` is relevant to a YANG module. Perversely, the point about the limit of the MTU for the system overlaps prior directorate commentary where there was worry that you could set this value arbitrarily large. Since Don't Fragment is set, you're limited by the system MTU. For purposes of the YANG module, you can't create a constraint vs. that system interface MTU that can be generically embedded in the YANG module. At best, it becomes ia commit check. This text is the best we can do in such circumstances to notify the user that the value is limited. If you disagree with this thinking, go debate with the YANG doctors as a whole for something better. EV> if authors/WG want to keep it like it is, then this point is solved. My AD review is also to check whether choices were made on purpose. It seems required for any YANG model to state whether it is NMDA compliant, and I see no such mention in this document. # Section 6 Could an on-path attacker selectively drop those Large Packets BFD to reduce the overall link efficiency by dropping the MTU ? On-path attackers capable of selectively dropping BFD packets will cause the protocol to go to the Down state upon the loss of N successive Detect Mult (BFD configuration parameter) number of packets. There's nothing we can do about this and is a base BFD security consideration. If the "attack" is that such an on-path attacker restricts the effective Path MTU, BFD will go Down. This accomplishes the extension goal of determining that the Path MTU is appropriate for the BFD clients. EVY> fair enough -- Jeff
