Jeff,
Please see inline... Best Regards, Xiao Min Original From: JeffreyHaas <jh...@pfrc.org> To: Reshad Rahman <res...@yahoo.com>; Cc: BFD WG <rtg-bfd@ietf.org>;Alexander Vainshtein <alexander.vainsht...@rbbn.com>;Nitsan Dolev <nitsan.do...@rbbn.com>;Shell Nakash <shell.nak...@rbbn.com>;James Lian <james.l...@rbbn.com>; 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 <jh...@pfrc.org> 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
