Hi Jeff, Gorry, I'm following your discussion to see whether some text change needed. Please see inline.
Original From: JeffreyHaas <[email protected]> To: Gorry Fairhurst <[email protected]>; Cc: [email protected] <[email protected]>;[email protected] <[email protected]>;[email protected] <[email protected]>; Date: 2024年10月16日 23:34 Subject: Re: UDP Guidelines and draft-ietf-bfd-unaffiliated-echo-12 Gorry, On Oct 16, 2024, at 3:02 AM, Gorry Fairhurst <[email protected]> wrote: On 15/10/2024 22:11, Jeffrey Haas wrote: Gorry, On Tue, Oct 15, 2024 at 05:26:04PM +0100, Gorry Fairhurst wrote: I have a few comments, but i am not a routing expert, so I'm maybe misisng context on the intended use, and why this is a good thing to allow.... I did not find a description of why this was needed. Like many IETF specifications, the use cases often get dropped from the work as the document proceeds through its discussion. [...] For me, that's much clearer than the text that appears in the draft, thank you for explaining. Could something like this appear in the spec.? As noted above, we usually start with the use cases in the document and they get removed across the process. I'm not in favor of it, but it's common. Consider for example the applicability section from section 4 of the adopted -00: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-01#section-4 It eventually was excised in version -04. I don't find appropriate traceability in mailarchive to show why that happened. GTSM, aka RFC 5082, isn't mentioned or used, but it seems to berelevent? If not, then the mechanism used to protect from forwarding needs more explanation. See the text covering TTL in the draft. That TTL text was what made me ask. I still think this might be a use fo GTSM, aka RFC 5082? If so, that's good for me, if you refer to it - if it's not, what is different? There is some concern that this isn't the normative GTSM. However, RFC 5082 Appendix A applies. [XM]>>> I can add the reference to RFC 5082 back to this document, if no objection from Dhruv (who had that concern). Propose to change the text as below. OLD All Unaffiliated BFD Echo packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255, and received with a TTL or Hop Limit value of 254, otherwise the received packets MUST be dropped.NEW All Unaffiliated BFD Echo packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255, and received with a TTL or Hop Limit value of 254, otherwise the received packets MUST be dropped ([RFC5082] Appendix A).END Cheers, Xiao Min
