Jeff and other authors, Thanks for your patience on this one.
Except for the point below EVY2>, all is clear and good to go. Thank you, Reshad, for the updated shepherd’s write-up. Please fix at least the EVY2> about the SHOULD (and think about my suggestion for the security section), then I will move forward with the IETF last call. Regards -éric From: Jeffrey Haas <jh...@pfrc.org> Date: Friday, 11 October 2024 at 17:59 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: rtg-bfd@ietf.org <rtg-bfd@ietf.org>, John Scudder <j...@juniper.net>, af...@bloomberg.net <af...@bloomberg.net>, Reshad Rahman <res...@yahoo.com> Subject: Re: Alternate AD review of draft-ietf-bfd-large-packets-11 [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) <evyn...@cisco.com<mailto:evyn...@cisco.com>> 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. EVY2> ;-) 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? EVY2> indeed, my bad on this one... all is good 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. EVY2> understood (even if too drastic to my taste though), but then be clear about the drastic consequence when the SHOULD is ignored else my fellow ADs will complain about a SHOULD used improperly (i.e., w/o enough explanations) # 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. EVY2> Up to you even if I still wonder why my suggestion is refused. 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. EVY2> suggest then adding “The above text also applies to most if not all BFD techniques” 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. EVY2> AFAIK, it is really mandatory in YANG model RFCs. So, it is a good addition. # 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. EVY2> and the provided justification (thanks for it) should be added in the section if only to avoid another comments -- Jeff
