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 <reshad= > [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 >> >> >> <http://www.zte.com.cn/> >> Original >> *From: *ReshadRahman <[email protected]> >> *To: *[email protected] <[email protected]>;[email protected] <[email protected]>; >> 张征00007940; >> *Date: *2024年07月08日 03:56 >> *Subject: **Re: Call for review for draft-ietf-bier-bfd* >> Hi, >> >> 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] >> >
