[Response to original mail to track the main points.] Thanks for your patience for this next update. My responses here will be reflected in an updated version that will ship in parallel with this email.
> On Aug 14, 2024, at 7:58 AM, Eric Vyncke (evyncke) <[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 ? We briefly discussed the ECMP topic. Basically, it's substantive enough that the WG could take this up as a piece of work. However, the working group's energy is very low and we were primarily discussing shutting down BFD. The conclusion was instead to enter hibernation mode since IETF benefitted from not fully decommissioning the working group. This continues the trend of "the shortest lived working group ever" that Alex Zinin promised me 20 years ago continuing. At least the work isn't awful. Relevant to the question, Robert's observation doesn't change the fundamentals of BFD and this draft doesn't worsen them. I'd suggest to Reshad that the point be noted in an update to the shepherd's report. > > 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 I'll leave this one to Reshad to update. > > # Abstract > > Please also state that a YANG module is also specified. I've added a new paragraph covering this point. > > `This document discusses thoughts` does not fit the ‘proposed standard’ > intended status. Let’s use “This document specifies” Updated. > > # 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 ? There are two motivations here: 1. Acknowledging prior art. 2. Noting that the prior art had deficiencies when dealing with the multihop case. Since BFD can be run over a number of encapsulations and modes, noting support for multihop as a requirement is important. > > s/i.e./i.e.,/ possibly in other places as well and also applies to ‘e.g.’, > which should be followed by a comma. Fixed in the places where it was not already done. > > s/certain minimum criteria/certain minimum criterion/ Done. > > # Section 3 > > Suggest adding a reference (including the section) to `new BFD variable` It is defined in section 3 itself. What change are you requesting? > > Add the units (octet I guess) for bfd.PaddedPduSize Added (in bytes) > > # Section 4.1 > > Be specific on “receiving implementation” in `the implementation would follow > normal BFD procedures` I've added receiving to two of the places implementation was used. > > # 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. From the other thread: 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. Trying a less restrictive setting is inconsistent with existing BFD behaviors. Thus, your observation is correct, and it is drastic. This is intentional. It is also a SHOULD and permits implementations that wish to try to selectively negotiate to less strict set of parameters do so. A form of such negotiation was raised by Xiao Min as part of discussing these MTU fetures and could leverage BFD Poll sequences. That said, it was appropriate for us to make a base recommendation. > > # Section 4.5 > > References to LAG & ECMP will be welcome. As noted in the other thread I don't think a pointer to the IEEE LAG specification is helpful and would prefer to avoid adding it unless required. > > 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 ? Answered in other thread. > > s/Mis-configuration/Misconfiguration/ Fixed. > > # Section 5.1 > > s/LAG and MPLS/LAG, and MPLS/ Done. > > # Section 5.2 > > Why are there double quotes around rt in `prefix "rt";` and not for other > prefixes ? Removed the quotations. > > Should there be a reference to RFC XXXX in `feature padding` ? Added. > > `padded-pdu-size` be consistent by using either octet or byte. I've chosen bytes for consistency. > Unsure whether `The maximum padded PDU size may be limited by the supported > interface MTU of the system` is relevant to a YANG module. As discussed in the other thread, we'll leave this. > > It seems required for any YANG model to state whether it is NMDA compliant, > and I see no such mention in this document. That didn't come up during Jürgen's review. I've added an NMDA conformance statement as part of my changes to the introduction. > > # Section 6 > > Could an on-path attacker selectively drop those Large Packets BFD to reduce > the overall link efficiency by dropping the MTU ? Answered in the other thread. -- Jeff
