Bruni, I might be over-interpreting what you say, but my conclusion is that we don't really if this a a problem. We could standardize draft-ietf-mpls-p2mp-bfd without adding any remedies for problems that might be imaginary. Then we ask operators about their experience and tailor and remedies based on experience from real live networks. /Loa > Hi Greg, > > Thanks for considering my comment and for your reply. > Iâ??m not following the draft but a priori my understand is that the > reporting from the egress to the root may happen at the discretion of the > egress, with no constraint in term of respecting any timing. If so, I > donâ??t see why we would need to be within 75% of a specific time limit. > We could a priori choose any value for this time limit (configured on the > egress or any default value) and pick a random number within 0% to 100% of > this limit. But you are likely to know much better than me, so up to you. > > Regards, > --Bruno > > From: Greg Mirsky <gregimirsky@xxxxxxxxx> > Sent: Monday, February 26, 2024 6:05 PM > To: DECRAENE Bruno INNOV/NET <bruno.decraene@xxxxxxxxxx> > Cc: rtg-dir@xxxxxxxx; draft-ietf-mpls-p2mp-bfd.all@xxxxxxxx; > last-call@xxxxxxxx; mpls@xxxxxxxx; Joel Halpern <jmh@xxxxxxxxxxxxxxx> > Subject: Re: [mpls] Rtgdir last call review of > draft-ietf-mpls-p2mp-bfd-06 > > Hi Bruno, > thank you for your interest and the suggestion. BFD spec (RFC 5880) > includes the mechanism intended to avoid synchronization of BFD Control > messages: > 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. > Do you think that the same randomization mechanism applied to the > transmission of notifications to the root of p2mp LSP would be useful? > > Regards, > Greg > > On Mon, Feb 26, 2024 at 2:45â?¯AM > <bruno.decraene@xxxxxxxxxx<mailto:bruno.decraene@xxxxxxxxxx>> wrote: > 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. Statiscally, 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<mailto:mpls-bounces@xxxxxxxx>> On Behalf > Of Greg Mirsky > Sent: Sunday, February 25, 2024 12:25 AM > To: Joel Halpern <jmh@xxxxxxxxxxxxxxx<mailto:jmh@xxxxxxxxxxxxxxx>> > Cc: rtg-dir@xxxxxxxx<mailto:rtg-dir@xxxxxxxx>; > draft-ietf-mpls-p2mp-bfd.all@xxxxxxxx<mailto:draft-ietf-mpls-p2mp-bfd.all@xxxxxxxx>; > last-call@xxxxxxxx<mailto:last-call@xxxxxxxx>; > mpls@xxxxxxxx<mailto: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. > ____________________________________________________________________________________________________________ > 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
