Hi Loa,
thank you for suggesting a mechanism that can minimize manual configuration. It lead me to look at the mechanism defined in RFC 5880:
The periodic transmission of BFD Control packets MUST be jittered on
a per-packet basis by up to 25%, that is, the interval MUST be
reduced by a random value of 0 to 25%, in order to avoid self-
synchronization with other systems on the same subnetwork. Thus, the
average interval between packets will be roughly 12.5% less than that
negotiated.
I think that might be helpful adding it, or similar, to the action of a leave that detects the failure.
Regards,
Greg
On Mon, Feb 26, 2024 at 3:54 AM <loa@xxxxx> wrote:
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 <mpls-bounces@xxxxxxxx> On Behalf Of Greg Mirsky
> Sent: Sunday, February 25, 2024 12:25 AM
> To: Joel Halpern <jmh@xxxxxxxxxxxxxxx>
> Cc: rtg-dir@xxxxxxxx; draft-ietf-mpls-p2mp-bfd.all@xxxxxxxx;
> last-call@xxxxxxxx; mpls@xxxxxxxx
> 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
> <jmh@xxxxxxxxxxxxxxx<mailto:jmh@xxxxxxxxxxxxxxx>> 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
> <noreply@xxxxxxxx<mailto:noreply@xxxxxxxx>> 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
> mpls@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/mpls
>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
