Hi Sasha,
As Mahesh has replied, we can't do this as an erratum. Doing a new document
with a module which augments ietf-bfd-lag would be the easiest solution, but I
don't think it's the way to go. A bis of 9314 is more appropriate.
Regards,Reshad.
On Monday, October 17, 2022, 03:10:18 PM EDT, Alexander Vainshtein
<[email protected]> wrote:
Reshad,Lots of thanks for a very encouraging response.
All,Any ideas how this should be handled (an Erratum, a 9314bis draft,
something else)?
Regards, and Lots of thanks in advance,Sasha
Get Outlook for Android
From: Reshad Rahman <[email protected]>
Sent: Monday, October 17, 2022, 21:01
To: BFD WG <[email protected]>; Alexander Vainshtein
<[email protected]>
Cc: Nitsan Dolev <[email protected]>; Shell Nakash <[email protected]>;
James Lian <[email protected]>
Subject: [EXTERNAL] Re: A missing read/write attribute in RFC 9314?
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>.
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.
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.
