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

[Greg Mirsky <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> On Behalf Of Greg Mirsky
> > Sent: Sunday, February 25, 2024 12:25 AM
> > To: Joel Halpern <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [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://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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
>