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>. 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>.
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.
<<attachment: winmail.dat>>
