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

[Joel Halpern <[e-mail]>]

Mostly.  THere is one other aspect.  You may consider it irrelevant, in 
which case we can simply say so.  Can the inbound notifications coming 
from a large number of leaves at the same time cause data plane congestion?

Yours,

Joel

On 2/24/2024 8:44 PM, Greg Mirsky wrote:
> Hi Joel,
> thank you for your quick response. I consider two risks that may 
> stress the root's control plane:
>
>   * notifications transmitted by the leaves reporting the failure of
>     the p2mp LSP
>   * notifications transmitted by the root to every leave closing the
>     Poll sequence
>
> As I understand it, you refer to the former as inbound congestion. The 
> latter - outbound. Is that correct? I agree that even the inbound 
> stream of notifications may overload the root's control plane. And the 
> outbound process further increases the probability of the congestion 
> in the control plane. My proposal is to apply a rate limiter to 
> control inbound flow of BFD Control messages punted to the control plane.
> What would you suggest in addition to the proposed text?
>
> Best regards,
> Greg
>
> On Sat, Feb 24, 2024 at 3:28 PM Joel Halpern 
> <[e-mail]> wrote:
>
>     What you say makes sense.  I think we need to acknowledge the
>     inbound congestion risk, even if we choose not to try to
>     ameliorate it.  Your approaches seems to address the outbound
>     congestion risk from the root.
>
>     YOurs,
>
>     Joel
>
>     On 2/24/2024 6:25 PM, Greg Mirsky wrote:
>>     Hi Joel,
>>     thank you for the clarification. My idea is to use a rate limiter
>>     at the root of the p2mp LSP that may receive notifications from
>>     the leaves affected by the failure. I imagine that the threshold
>>     of the rate limiter might be exceeded and the notifications will
>>     be discarded. As a result, some notifications will be processed
>>     by the headend of the p2mp BFD session later, as the tails
>>     transmit notifications periodically until the receive the BFD
>>     Control message with the Final flag set.  Thus, we cannot avoid
>>     the congestion but mitigate the negative effect it might cause by
>>     extending the convergence. Does that make sense?
>>
>>     Regards,
>>     Greg
>>
>>     On Sat, Feb 24, 2024 at 2:39 PM Joel Halpern
>>     <[e-mail]> wrote:
>>
>>         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.
>>>
>>>