Re: WGLC for draft-ietf-bfd-unaffiliated-echo (ending 7 April, 2023)

[Jeffrey Haas <[e-mail]>]

Xiao Min,


> On Apr 7, 2023, at 3:15 AM, [e-mail] wrote:
>>> On Apr 6, 2023, at 3:35 AM, <[e-mail] <mailto:[e-mail]>> <[e-mail] <mailto:[e-mail]>> 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.
> 
> 

That's an interesting deficiency.  I will ask Juniper BFD developers if there's any similar consideration for our current implementation.

> [XM]>>> I propose the text change as below.
> 
> OLD
> 
> Device A would send BFD Unaffiliated Echo packets with IP destination
>    address destined for itself, such as the IP address of interface 1 of
>    device A.
> NEW
> 
> Device A would send BFD Unaffiliated Echo packets with IP destination
>    address destined for itself, such as the IP address of interface 1 of
>    device A. The IP source address of the BFD Unaffiliated Echo packets
>    could be identical to the IP destination address or other address provisioned
>    on device A.
> 
> 
"could" isn't one of our RFC 2119 normative terms.  Do you believe "SHOULD" is more appropriate?

-- Jeff