[Bier] Re: Call for review for draft-ietf-bier-bfd

[Reshad Rahman <[e-mail]>]

 Greg, -07 looks good to me.
Regards,Reshad.
    On Friday, July 26, 2024 at 08:39:13 AM PDT, Greg Mirsky <[e-mail]> 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 <[e-mail]> 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=[e-mail]> 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, <[e-mail]> wrote:  
 
 
Hi Reshad, 

No problem for the extension. 

Thank you very much!


Best regards,

Sandy





OriginalFrom: ReshadRahman <[e-mail]>To: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;张征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, <[e-mail]> 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 -- [e-mail]
To unsubscribe send an email to [e-mail]