Jeff, I do not have a micro-BFD implementation that supports the optional behavior of 7130.
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. So I think that we indeed need a survey you have proposed. If there are no implementations exercising optional behavior, deprecating it in 7130 could be considered as well. Regards, Sasha Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Jeffrey Haas <[email protected]> Sent: Wednesday, October 19, 2022, 22:25 To: Reshad Rahman <[email protected]> Cc: BFD WG <[email protected]>; Alexander Vainshtein <[email protected]>; Nitsan Dolev <[email protected]>; Shell Nakash <[email protected]>; James Lian <[email protected]> Subject: [EXTERNAL] Re: A missing read/write attribute in RFC 9314? 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.) Sasha, did you have an implementation needing this knob that triggered this investigation? -- Jeff Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
