Jeff,
To clarify ZTE's implementation, please see inline... 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年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. 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
