Greg, -07 looks good to me.
Regards,Reshad.
On Friday, July 26, 2024 at 08:39:13 AM PDT, Greg Mirsky
<[email protected]> wrote:
Hi Reshad,I've uploaded -07 version that includes all the updates. I hope that
we've satisfactorly addressed your concerns.
Regards,Greg
On Mon, Jul 22, 2024 at 10:25 PM Greg Mirsky <[email protected]> wrote:
Hi Reshad,thank you for your comments and helpful suggestions. Please find my
notes below tagged GIM>>. Also, attached are the new working version of the
draft nad the diff highlighting the applied updates.
Regards,Greg
On Tue, Jul 16, 2024 at 7:29 PM Reshad Rahman
<[email protected]> wrote:
Hi,
Here are my comments:
- Section 1, 2nd paragraph, states that RFC8562 defines a method for BFD to
detect unicast failures between the sender and receivers in multipoint or
multicast networks. Should that just say "detect failures" (remove unicast)
instead?
GIM>> Thank you for the suggestion. Agreed.
- Section 4, last paragraph. It says "this discriminator", should that be "My
Discriminator"?
GIM>> Great catch, thank you! Done.
- Section 4.1, last paragraph. Typo "the My Discriminator field n the" -> "the
My Discriminator field in the"
GIM>> Good catch, thank you! (I noticed two more occurences, so, triple
thanks!)
- Section 5.6 of RFC8562 on Session Establishment mentions that "Sessions on
the tail MAY be established dynamically, based on the receipt of a multipoint
BFD Control packet from the head". In this document it seems to be implied that
sessions on the BFERs (tail nodes) are established via the bootstrapping
mechanism. Whether true or not, this should be explicitly stated one way or the
other.
GIM>> A good point. I propose the follwoing update:OLD TEXT: As defined in
[RFC8562], a BIER BFD session MAY be established to monitor the state of the
multipoint path. The BIER BFD session could be created for each multipoint
path and the set of BFERs over which the BFIR is requested to run BIER BFD.
The BFIR MUST advertise the multipoint path and the value of My Discriminator
associated with the path to the set of BFERs. The BFIR MUST bootstrap the
BFD session and advertise the BFD information to the set of BFERs.
Bootstrapping a BIER BFD session MAY use BIER OAM message (Section 4.1) or
the control plane (Section 4.2, Section 4.3).
The BIER BFD bootstrapping MUST be repeated when the value of this
discriminator being changed.NEW TEXT:
As defined in [RFC8562], a BIER BFD session MAY be established to monitor
the state of the multipoint path. The BIER BFD session could be created for
each multipoint path and the set of BFERs over which the BFIR is requested to
run BIER BFD. The BFIR, according to Section 5.7 of [RFC8562], MAY bootstrap
the BFD session using a BIER OAM message (Section 4.1) or the control plane
(Section 4.2, Section 4.3). Either method MUST refer to the multipoint path
and the value of My Discriminator associated with the path to the set of
BFERs. The BIER BFD bootstrapping MUST be repeated when the value of My
Discriminator is changed.
I hope that addresses your concern.
- Section 6.1, any concerns that the BFIR could be overwhelmed by a spike of
incoming BFD control packets? I see this is not mentioned in RFC8563.
GIM>> A great question, thank you. I agree, the number of BFERs affected by a
failure might be significant thus causing a spike of notifications. I've
updated text in Section 6.1:OLD TEXT: To improve the likelihood of notifying
the BFIR of the failure, the BFER SHOULD transmit three BFD Control packets
defined above in short succession.NEW TEXT: To improve the likelihood of
notifying the BFIR of the failure, the BFER SHOULD transmit three BFD Control
packets defined above in with pseudo-random intervals between packets within
a one-second interval.
Furthermore, updated Security Considerations as follows:OLD TEXT: No
additional security issues are raised in this document beyond those that
exist in the referenced BFD documents.NEW TEXT: A single failure could affect
a significant number of BFERs, thus causing a spike in the number of BFD
Control packets with notifications, as defined in Section 6.1. To mitigate
the overloading of the control plane, an implementation MUST control the
number of BFD Control packets passed to the control plane for processing.
Finally, shouldn't LSR WG also take a look at this doc (even though Les has
already provided comments)?
GIM>> Working on addressing Les' comments.
Regards,Reshad.
On Sunday, July 7, 2024 at 08:32:38 PM EDT, <[email protected]> wrote:
Hi Reshad,
No problem for the extension.
Thank you very much!
Best regards,
Sandy
OriginalFrom: ReshadRahman <[email protected]>To: [email protected]
<[email protected]>;[email protected] <[email protected]>;张征00007940;Date: 2024年07月08日
03:56Subject: Re: Call for review for draft-ietf-bier-bfdHi,
Thanks Sandy for forwarding the document to the BFD WG.
I was planning to review this document but work and a work-trip got in the way.
Could we please get a 1-week extension?
BFD WG, please review this document.
Regards,Reshad.
On Tuesday, June 25, 2024 at 03:26:28 AM EDT, <[email protected]> wrote:
Hi,
The draft-ietf-bier-bfd passed last call in BIER WG.
We'd like to get more review in BFD WG:
https://datatracker.ietf.org/doc/draft-ietf-bier-bfd/
Comments and suggestion welcomed, please send your comments before 9th, July.
And please volunteer if you want to be the shepherd of this draft.
Thank you!
Best regards,
Sandy
_______________________________________________
BIER mailing list -- [email protected]
To unsubscribe send an email to [email protected]
