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

Joel Halpern <jmh.direct@xxxxxxxxxxxxxxx> · Sat, 24 Feb 2024 18:28:50 -0500



    What you say makes sense.  I think we need to acknowledge the
      inbound congestion risk, even if we choose not to try to
      ameliorate it.  Your approaches seems to address the outbound
      congestion risk from the root.
    YOurs,
    Joel

    
    On 2/24/2024 6:25 PM, Greg Mirsky
      wrote:

    
      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>
          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>
                  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.

                  
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call