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

[Greg Mirsky <[e-mail]>]

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
>
>
> <http://www.zte.com.cn/>
> Original
> *From: *ReshadRahman <[e-mail]>
> *To: *[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
> 张征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, <[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]
>