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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Feb 24, 2024, at 15:34, Greg Mirsky <gregimirsky@xxxxxxxxx> 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.


S/passed to processing in the control place of the ingress LSR./passed to the ingress LSR’s control plane for processing./ 

Acee

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.


_______________________________________________
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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux