And to add to Reshad’s comment, unfortunately we cannot add a node to the model as an erratum. It can be added as an augmentation of the model, or a -bis version of the draft, both of which requires a draft. Thanks
> On Oct 17, 2022, at 11:01 AM, Reshad Rahman > <[email protected]> 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. > > Regards, > Reshad. > > On Thursday, September 29, 2022, 11:04:41 AM EDT, Alexander Vainshtein > <[email protected]> wrote: > > > Hi, > I have a question/comment about what looks to me a missing attribute in the > BFD YANG Data Model defined in RFC > 9314<https://datatracker.ietf.org/doc/html/rfc9314 > <https://datatracker.ietf.org/doc/html/rfc9314>>. > This standard covers, among many others BFD flavors, the so-called micro-BFD > sessions on LAG members defined in RFC > 7130<https://www.rfc-editor.org/rfc/rfc7130.html > <https://www.rfc-editor.org/rfc/rfc7130.html>>. > > Section 2.3 of RFC 7130 "Micro-BFD Session Ethernet Details" defines says > (the relevant text is highlighted): > > On Ethernet-based LAG member links, the destination Media Access > Control (MAC) is the dedicated multicast MAC address > 01-00-5E-90-00-01 to be the immediate next hop. This dedicated MAC > address MUST be used for the initial BFD packets of a micro-BFD > session when in the Down/AdminDown and Init states. When a micro-BFD > session is changing into the Up state, the first bfd.DetectMult > packets in the Up state MUST be sent with the dedicated MAC. For BFD > packets in the Up state following the first bfd.DetectMult packets, > the source MAC address from the received BFD packets for the session > MAY be used instead of the dedicated MAC. > > 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. > > The highlighted text suggests to me that the module ietf-bfd-lag should, for > each session, contain a Boolean r/w attribute controlling ability of the > session to send, after reaching its UP state and transmitting the first > bfd.DetectMult packets in this state with the dedicated (well-known > multicast) destination MAC address 01-00-5e-90-00-01, to switch to > transmitting packets with the received MAC address. The default value of this > attribute should be FALSE (i.e., this ability by default should be disabled). > > Unfortunately, I have not found any such attribute in RFC 9314. > Did I miss something substantial? > > Regards, and lots of thanks in advance, > Sasha > > > 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. > <winmail.dat> Mahesh Jethanandani [email protected]
