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
