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


> On Feb 24, 2024, at 15:34, Greg Mirsky <gregimirsky@gmail.com> 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@ietf.org <mailto:noreply@ietf.org>> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls