Jeff,
Please see inline... Best Regards, Xiao Min Original From: JeffreyHaas <[email protected]> To: Reshad Rahman <[email protected]>; Cc: BFD WG <[email protected]>;Alexander Vainshtein <[email protected]>;Nitsan Dolev <[email protected]>;Shell Nakash <[email protected]>;James Lian <[email protected]>; Date: 2022年10月20日 20:52 Subject: Re: A missing read/write attribute in RFC 9314? On Oct 19, 2022, at 3:24 PM, Jeffrey Haas <[email protected]> wrote: I think what this work looks like is:1. Survey of implementations to see whether they do this behavior, and whattheir knob is, if so. I have confirmed that Juniper's implementation does not support the behavior described in this thread. When in the Up state, Juniper's BFD on LAG uses the discovered unicast MAC address. Xiao Min reports that ZTE's implementation behaves similarly. [XM]>>> I see the similarity is that there is no any knob, at the same time, it seems different destination MAC is selected. In ZTE's implementation, the dedicated multicast MAC is used, while in Juniper's implementation, the discovered unicast MAC is used. Then, my question is, would it be recognizable for Juniper node when receiving BFD control packet with dedicated multicast MAC from ZTE node? It'd be good to get responses from Cisco, Huawei, and Nokia. -- Jeff
