Jeff,
Please see inline... Original From: JeffreyHaas <jh...@pfrc.org> To: 肖敏10093570; Cc: gregimir...@gmail.com <gregimir...@gmail.com>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>; Date: 2023年04月07日 23:32 Subject: Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023) Xiao Min, On Apr 7, 2023, at 3:15 AM, xiao.m...@zte.com.cn wrote: That's an interesting deficiency. I will ask Juniper BFD developers if there's any similar consideration for our current implementation. "could" isn't one of our RFC 2119 normative terms. Do you believe "SHOULD" is more appropriate? [XM-2]>>> If we would like to use normative term for SA, then that can also apply to DA, suggest s/would/MUST. As Greg pointed out, there may be implicit conflict with RFC 5881 section 4 that says "In particular, the source address SHOULD NOT be part of the subnet bound to the interface over which the BFD Echo packet is being transmitted". Best Regards, Xiao Min -- Jeff On Apr 6, 2023, at 3:35 AM, <xiao.m...@zte.com.cn> <xiao.m...@zte.com.cn> wrote: One of the considerations may be whether a IPv6 link local address is preferable to a global address. The only consideration for the draft as it is written is that the address used as the destination may be looped back by the unaffiliated device. Link local helps address the security considerations that impact this feature, and it might be worth noting that when link local can be used for the use case that it assists in this point. [XM]>>> I checked this with the implementer of this feature, and I'm told setting the DA to a IPv6 link local address doesn't work, because the link local address can't be looped back by the neighboring device.
