Jeff,
Thank you for the quick reply. Please see inline... Original From: JeffreyHaas <jh...@pfrc.org> To: 肖敏10093570; Cc: Reshad Rahman <res...@yahoo.com>;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.l...@rbbn.com <james.l...@rbbn.com>; Date: 2022年11月04日 19:22 Subject: Re: A missing read/write attribute in RFC 9314? Thank you for the correction and apologies for my error in copying, Xiao Min.[XM]>>> That's all right. :-) It would seem that Juniper is unique in using the learned MAC address for the session. :-) [XM]>>> Yes, it looks so. Actually I'm curious what's the behavior of Juniper's node if it receives a BFD control packet with the dedicated multicast MAC. Best Regards, Xiao Min However, none of the implementations permit dynamic use of both. We have compliant implementations that do not need additional YANG configuration. -- Jeff On Nov 3, 2022, at 9:09 PM, <xiao.m...@zte.com.cn> <xiao.m...@zte.com.cn> wrote: Jeff, To clarify ZTE's implementation, please see inline... 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年11月04日 07:17 Subject: Re: A missing read/write attribute in RFC 9314? [In an attempt to close this thread, replying to my older message...]On Wed, Oct 19, 2022 at 03:24:57PM -0400, Jeffrey Haas wrote:> On Mon, Oct 17, 2022 at 06:01:05PM +0000, Reshad Rahman wrote:> > Hi Sasha,> > Apologies for the delay.> > Yes this config knob is not present in RFC9314. I don't think it's something we did not add on purpose, afair it's something we missed. > > I'm going to offer a contrary view. Given that it may save us some work,> that might be appreciated. :-)> > Repeating the relevant bit of text:> > > All implementations MUST be able to send and receive BFD packets in> > Up state using the dedicated MAC address. Implementations supporting> > both, sending BFD Up packets with the dedicated and the received MAC,> > need to offer means to control the behavior.> > We have a mandatory mode, and an OPTIONAL mode. The BFD YANG module is> supporting, effectively, the mandatory.> > Modeling-wise, what we'd be looking for is adding this knob protected under> the appropriate new if-feature for it.> > I think what this work looks like is:> 1. Survey of implementations to see whether they do this behavior, and what> their knob is, if so.> 2a. If no implementations have such a knob, it's quite reasonable to just let> the vendor do their own augmentation module for it.> 2b. If multiple vendors implement it, we need an update.> 3. If we need an update, one path is to -bis RFC 9314, the other is to> simply do a trivial augmentation RFC. (Mahesh notes this point in his> reply.)What we have seen in a partial vendor implementation survey:- Arrcus only uses the dedicated multicast MAC for the Up session (mjethanandani)- Huawei only uses the dedicated multicast MAC for the Up session (mach.chen)- Juniper will use the discovered unicast MAC for the Up session. (jhaas) - ZTE will use the discovered unicast MAC for the Up session. (xiao.min) [XM]>>> That's NOT what I replied to the survey [1]. The correct one is as below. - ZTE only uses the dedicated multicast MAC for the Up session. (xiao.min) [1] https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/ Best Regards, Xiao Min None of these implementations support a knob to choose the behavior. Theypick a mode and stick with it.My conclusion is that we likely do not need an IETF update to the BFD YANGmodule here. If an implementation comes into being that makes thisselectable, YANG permits vendor augmentation to address the additionalconfiguration state.If it becomes the case that multiple vendors implement such a knob, IETFshould consider the trivial augmentation module to standardize the knob toprovide for ease of interop.To say that I'm relieved that we don't need a further update to BFD YANG atthis time is an understatement. :-)-- Jeff
