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 # 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. # Section 4.5 References to LAG & ECMP will be welcome. 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 ? 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. 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 ?
