Hi Loa, > From: Loa Andersson <loa.pi.nu@xxxxxxxxx> > Sent: Friday, March 1, 2024 6:04 AM > > Bruno, > > Are you saying that you have experiences where scenarios that are (a least to some extent) similar to p2mp-bfd may cause control plain overload in uplink nodes, that is good enough for me. Yes, for some definition of control plane overload : at least all packets could not reach the control plane. (although one could possibly blame the implementation, that's the way it is) > Based on your input I’d say that for the time being we raise the point, and work on mitigation techniques when we need them. Looks good to me. Thanks. --Bruno > /Loa > > PS > I hope I did not give the impression that you were trying to block anything, on the contrary I hoped that you could give us operator inpot to help us navigate. Not at all. On my side, I was trying to express to not hold the document for me. That's was just a feedback FYI > > Sent from my iPhone > > > On 1 Mar 2024, at 01:18, bruno.decraene@xxxxxxxxxx wrote: > > > > Hi Loa, > > > >> From: loa@xxxxx <loa@xxxxx> > >> Sent: Thursday, February 29, 2024 1:18 PM > >> > >> 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. > > > > I don't think that the problem is imaginary. Also having worked on scaling IS-IS flooding, if we assume that one node can be overloaded by its IGP neighbors, it seems logical that it could more easily be overloaded by possibly the whole set of LSRs in the domain. > > That being said, I can live with the draft raising the point and not > > providing mitigations technics. Or indicating some mitigation technics > > as MAY (IOW which won't be implemented) > > > > (also I was trying to help, not block anything) > > > > --Bruno > > > >> 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://wi/ > >>> ki%2F&data=05%7C02%7Cbruno.decraene%40orange.com%7C68a2e01bb96c40ed0 > >>> a4208dc39acff04%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6384486 > >>> 62382524744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > >>> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OFU0eJ7gXC1Zio > >>> xHaFgQMNQjqmnsX0elJyKJHFo0JD0%3D&reserved=0 > >>> .ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Cbruno.decraene% > >>> 40 > >>> orange.com%7Ca9033ca2b2274249bd6708dc39208e6d%7C90c7a20af34b40bfbc48 > >>> b9 > >>> 253b6f5d20%7C0%7C0%7C638448060180305786%7CUnknown%7CTWFpbGZsb3d8eyJW > >>> Ij > >>> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000 > >>> %7 > >>> C%7C%7C&sdata=x%2Fh9ksoMdueKOCTLCet4GICoCr%2BpF74ZiJLK%2FfM52uA%3D&r > >>> es > >>> erved=0 > >>> > >>> 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%2Fmailman%2Flistinfo%2Fmpls&data=05%7C02%7Cbruno.decraene%4 > >>> 0o > >>> range.com%7Ca9033ca2b2274249bd6708dc39208e6d%7C90c7a20af34b40bfbc48b > >>> 92 > >>> 53b6f5d20%7C0%7C0%7C638448060180315645%7CUnknown%7CTWFpbGZsb3d8eyJWI > >>> jo > >>> iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000% > >>> 7C > >>> %7C%7C&sdata=kxPudg6wfV5yRV9%2FfZI%2F8vj7XgSrVDe%2F2O4Cs%2FwEorY%3D& > >>> re > >>> served=0 > >>> > >> > >> > >> > > ______________________________________________________________________ > > ______________________________________ > > 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 > ____________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
