Re: [mpls] Rtgdir last call review of draft-ietf-mpls-p2mp-bfd-06

[Joel Halpern <[e-mail]>]

That covers part of my concern.  But....  A failure near the root means 
that a lot of leaves will see failure, and they will all send 
notifications converging on the root.  Those notifications themselves, 
not just the final messages, seem able to cause congestion.  I am not 
sure what can be done about it, but we aren't allowed to ignore it.

Yours,

Joel

On 2/24/2024 3:34 PM, Greg Mirsky wrote:
> Hi Joel,
> thank you for your support of this work and the suggestion. Would the 
> following update of the last paragraph of Section 5 help:
> OLD TEXT:
>    An ingress LSR that has received the BFD Control packet, as described
>    above, sends the unicast IP/UDP encapsulated BFD Control packet with
>    the Final (F) bit set to the egress LSR.
> NEW TEXT:
>    As described above, an ingress LSR that has received the BFD Control
>    packet sends the unicast IP/UDP encapsulated BFD Control packet with
>    the Final (F) bit set to the egress LSR.  In some scenarios, e.g.,
>    when a p2mp LSP is broken close to its root, and the number of egress
>    LSRs is significantly large, the control plane of the ingress LSR
>    might be congested by the BFD Control packets transmitted by egress
>    LSRs and the process of generating unicast BFD Control packets, as
>    noted above.  To mitigate that, a BFD implementation that supports
>    this specification is RECOMMENDED to use a rate limiter of received
>    BFD Control packets passed to processing in the control plane of the
>    ingress LSR.
>
> Regards,
> Greg
>
> On Thu, Feb 22, 2024 at 4:10 PM Joel Halpern via Datatracker 
> <[e-mail]> wrote:
>
>     Reviewer: Joel Halpern
>     Review result: Ready
>
>     Hello,
>
>     I have been selected as the Routing Directorate reviewer for this
>     draft. The
>     Routing Directorate seeks to review all routing or routing-related
>     drafts as
>     they pass through IETF last call and IESG review, and sometimes on
>     special
>     request. The purpose of the review is to provide assistance to the
>     Routing ADs.
>     For more information about the Routing Directorate, please see
>     https://wiki.ietf.org/en/group/rtg/RtgDir
>
>     Although these comments are primarily for the use of the Routing
>     ADs, it would
>     be helpful if you could consider them along with any other IETF
>     Last Call
>     comments that you receive, and strive to resolve them through
>     discussion or by
>     updating the draft.
>
>     Document: draft-name-version
>     Reviewer: your-name
>     Review Date: date
>     IETF LC End Date: date-if-known
>     Intended Status: copy-from-I-D
>
>     Summary:  This document is ready for publication as a Proposed
>     Standard.
>         I do have one question that I would appreciate being considered.
>
>     Comments:
>         The document is clear and readable, with careful references
>     for those
>         needing additional details.
>
>     Major Issues: None
>
>     Minor Issues:
>         I note that the security considerations (section 6) does refer to
>         congestion issues caused by excessive transmission of BFD
>     requests.   I
>         wonder if section 5 ("Operation of Multipoint BFD with Active
>     Tail over
>         P2MP MPLS LSP") should include a discussion of the congestion
>     implications
>         of multiple tails sending notifications at the rate of 1 per
>     second to the
>         head end, particularly if the failure is near the head end. 
>     While I
>         suspect that the 1 / second rate is low enough for this to be
>     safe,
>         discussion in the document would be helpful.
>
>