Thank you for the correction and apologies for my error in copying, Xiao Min.
It would seem that Juniper is unique in using the learned MAC address for the session. :-) 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... > > Original > From: JeffreyHaas <jh...@pfrc.org <mailto:jh...@pfrc.org>> > To: Reshad Rahman <res...@yahoo.com <mailto:res...@yahoo.com>>; > Cc: BFD WG <rtg-bfd@ietf.org <mailto:rtg-bfd@ietf.org>>;Alexander Vainshtein > <alexander.vainsht...@rbbn.com <mailto:alexander.vainsht...@rbbn.com>>;Nitsan > Dolev <nitsan.do...@rbbn.com <mailto:nitsan.do...@rbbn.com>>;Shell Nakash > <shell.nak...@rbbn.com <mailto:shell.nak...@rbbn.com>>;James Lian > <james.l...@rbbn.com <mailto: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/>https://mailarchive.ietf.org/arch/msg/rtg-bfd/_Ie2xUP5UskH3M2yE4V-JVO8g_g/ > <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. They > pick a mode and stick with it. > > My conclusion is that we likely do not need an IETF update to the BFD YANG > module here. If an implementation comes into being that makes this > selectable, YANG permits vendor augmentation to address the additional > configuration state. > > If it becomes the case that multiple vendors implement such a knob, IETF > should consider the trivial augmentation module to standardize the knob to > provide for ease of interop. > > To say that I'm relieved that we don't need a further update to BFD YANG at > this time is an understatement. :-) > > -- Jeff
