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

[[e-mail]]

Bruno,

I'm not responding for Greg, I guess he will respond for himself soon.

What you describe is very attractive and I think it will be implemented.

However, I think that what Greg was looking for was something that
wouldn't need to configured.

/Loa

> Hi Greg,
>
> My 2 cents (not following the draft).
> Another typical option may be to allow the network operator to configure,
> on the egress, an acceptable delay before reporting to the root. The
> egress would then pick a random value in this range. Statically, the more
> egress the more spread the reports to the root, which a priori would be
> good for scaling.
> It would be up to the network operator to configure the right delay
> depending on the number of the leaves and the need for fast reporting (or
> not).
>
> Totally up to you, but that would have my vote as this is a typical issue.
> (granted this is more likely an issue with protocols handling thousands of
> customers, but even for MPLS LSR scaling, RSVP-TE scaling issues are not
> unheard)
>
> Regards,
> --Bruno
>
> From: mpls <[e-mail]> On Behalf Of Greg Mirsky
> Sent: Sunday, February 25, 2024 12:25 AM
> To: Joel Halpern <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [mpls] Rtgdir last call review of
> draft-ietf-mpls-p2mp-bfd-06
>
> 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]<mailto:[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]<mailto:[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.
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>