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

[Greg Mirsky <[e-mail]>]

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
>>
>>
>> <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]
>>
>