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

[Greg Mirsky <[e-mail]>]

Hi Bruno,
your feedback is always appreciated; thank you for a good discussion. I
will add the optional use of jitter for the unsolicited notification to the
draft with the default range of 25% of the interval between notifications
and optional control to change the range. WDYT?

Regards,
Greg

On Thu, Feb 29, 2024 at 9:18 AM <[e-mail]> wrote:

> Hi Loa,
>
> > From: [e-mail] <[e-mail]>
> > 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 <[e-mail]>
> > > Sent: Monday, February 26, 2024 6:05 PM
> > > To: DECRAENE Bruno INNOV/NET <[e-mail]>
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]; [e-mail]; Joel Halpern <[e-mail]>
> > > 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
> > > <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> On
> > > Behalf Of Greg Mirsky
> > > Sent: Sunday, February 25, 2024 12:25 AM
> > > To: Joel Halpern <[e-mail]<mailto:[e-mail]>>
> > > Cc: [e-mail]<mailto:[e-mail]>;
> > > [e-mail]<mailto:draft-ietf-mpls-p2mp-bfd.
> > > [e-mail]>; [e-mail]<mailto:[e-mail]>;
> > > [e-mail]<mailto:[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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
> > > .ietf.org%2Fen%2Fgroup%2Frtg%2FRtgDir&data=05%7C02%7Cbruno.decraene%40
> > > orange.com%7Ca9033ca2b2274249bd6708dc39208e6d%7C90c7a20af34b40bfbc48b9
> > > 253b6f5d20%7C0%7C0%7C638448060180305786%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7
> > > C%7C%7C&sdata=x%2Fh9ksoMdueKOCTLCet4GICoCr%2BpF74ZiJLK%2FfM52uA%3D&res
> > > 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
> > > [e-mail]
> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf.org%2Fmailman%2Flistinfo%2Fmpls&data=05%7C02%7Cbruno.decraene%40o
> > > range.com%7Ca9033ca2b2274249bd6708dc39208e6d%7C90c7a20af34b40bfbc48b92
> > > 53b6f5d20%7C0%7C0%7C638448060180315645%7CUnknown%7CTWFpbGZsb3d8eyJWIjo
> > > 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.
>