Dear Eric, Thank you very much for your review and the comments on draft-ietf-bfd-unaffiliated-echo. We appreciate you taking the time to provide this feedback as the alternate responsible AD. The authors will address the points you raised and provide a revised version of the I-D as soon as possible. We look forward to working with you to get this document published.
Best regards, Weiqiang on behalf of authors From: Eric Vyncke (evyncke) Date: 2024-09-20 17:09 To: [email protected] CC: John Scudder; [email protected]; [email protected]; [email protected]; Reshad Rahman; [email protected]; Jeffrey Haas Subject: Alternate AD review of draft-ietf-bfd-unaffiliated-echo-10 Dear BFD, dear authors, To lighten John Scudder’s workload, I will be the alternate responsible AD for draft-ietf-bfd-unaffiliated-echo. As I am an INT AD, please bear with me if I state something wrong about BFD ;-) First of all: thanks to the authors and the WHG for authoring this I-D and to Jeff Haas for being the shepherd. 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 :-) Regards -éric # Abstract s/ This document proposes a use of the BFD Echo/ This document defines a use of the BFD Echo/ s/but the neighboring system does/but the adjacent system does/ ? (to be consistent with S1) # Generic The section 1 should include some explanations about how packets are looped back to the source. RFC 5881 says ‘no LLA and not the subnet addresses’, so which addresses are used for source and destination ? The addressing probably deserves one section in the document. # Section 1 s/Full BFD protocol capability with affiliated Echo function/Full BFD protocol capability in the local and adjacent systems/ ? As the term ‘affiliated’ is defined in a subsequent paragraph and is not defined in RFC 5880. In `BFD Echo-Only method without full BFD protocol capability` should “in the adjacent system” be added ? Does it make sense to refer to an expired draft, draft-wang-bfd-one-arm-use-case-00 ? Expiration was in 2020... s/This document describes the use/This document specifies the use/ It is a standard track document after all ;-) # Section 2 Suggest using aasvg for nicer picture in rendering About figure 1, unsure whether “interface 1” adds anything, suggest removing (same for the top “Device A” and “Device B”). s/with zeroed "Your Discriminator"/with zeroed "Your Discriminator" field/ s/which is conformed to/which is conform to/ ? As I am not an English speaker, I wonder whether “with a certain value” is really the appropriate wording. The use of SHOULD should come with explanation of what happens if the SHOULD is bypassed (i.e., the previous issue of memory disclosure should be moved here). At the end of this section, the BFD fields are not enclosed in double quotes, they should be for clarity as well as to be consistent with the previous text. # Section 3 Bear with my lack of expertise in BFD, but can this be achieved `Demand mode MUST NOT be active if the session goes Down`? # Section 4 Unsure whether it brings any value, either delete this applicability section or move it as a subsection of the introduction ? # Section 5 As I wrote above, it is unclear for me (and probably many readers) what are the src/dst addresses of the IP packets, i.e., I cannot understand whether uRPF must be disabled or not. => an addressing considerations section is welcome with some examples. About the GSTM, as the technique clearly specifies that the adjacent system does not implement BFD, how can this document require that looping is only done with TTL/HL=255 ? RFC 8704 does not define a strict mode uRPF, so, remove this reference.
