Jeff, Sasha, Reshad, et al.,
Please see inline... Best Regards, Xiao Min Original From: JeffreyHaas <jh...@pfrc.org> To: Alexander Vainshtein <alexander.vainsht...@rbbn.com>; Cc: Reshad Rahman <res...@yahoo.com>;BFD WG <rtg-bfd@ietf.org>;Nitsan Dolev <nitsan.do...@rbbn.com>;Shell Nakash <shell.nak...@rbbn.com>;James Lian <james.l...@rbbn.com>; Date: 2022年10月20日 04:17 Subject: Re: [EXTERNAL] Re: A missing read/write attribute in RFC 9314? Sasha, On Wed, Oct 19, 2022 at 08:07:06PM +0000, Alexander Vainshtein wrote: > And I have not encountered implementations by other vendors that support this > option (with or without the knob in question). My guess (FWIW) is that this > would make an implementation much more complicated while the benefits would > be minimal. BFD on LAG was a contentious and fussy bit of RFC work. Much of the earlier headache about whether multicast or unicast MACs were to be involved had to do with chip details. However, I suspect as time has passed and it's become a more common feature across the vendors, things may have stabilized. > So I think that we indeed need a survey you have proposed. I've internally enquired about this at Juniper. A brief survey of some other implementations' manuals doesn't seem to suggest any knob for this behavior. It'd be good to get more formal statement of compliance from these vendors. [XM]>>> I've consulted my colleagues having implemented BFD on LAG at ZTE, only the dedicated multicast MAC is used and there is no any knob (also not suggested). > If there are no implementations exercising optional behavior, deprecating it > in 7130 could be considered as well. Absolutely. That would be an appropriate errata response once we have some data. [XM]>>> Yes, it seems more appropriate to take action on RFC 7130 rather than 9314. -- Jeff
