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

Acee Lindem <acee.ietf@gmail.com> Sat, 24 February 2024 22:21 UTC

Return-Path: <acee.ietf@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295E6C14F5FB; Sat, 24 Feb 2024 14:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Evr1rgxxEm2l; Sat, 24 Feb 2024 14:21:11 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B89C14EB17; Sat, 24 Feb 2024 14:21:11 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id 6a1803df08f44-68f51c5f9baso11137536d6.3; Sat, 24 Feb 2024 14:21:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708813270; x=1709418070; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=0d0G2iv1lB/F5FVX2gdxbboYBMkYUC9mc/kMiOes1/E=; b=X9hCE42/ipm4+XpurU321p3YYiZm8zE5hmP/oJEDkTmGkiAQjoWKKB28cvJRNuCfE4 1T85ZRLRIjug7dxqIYM/+PR7cF3ZxeHVAu2ELFFUjTwmHLOzXJsiSHGSqFW0uGawvXum 5jYAUqahmAi+kBLoOoH7y6cdwJa241AYoK7yRpvAvY76N/9wVyKp94zY9MK9MW5vkBJy mIEtX3AuWPTnQleGtwG5SVtNpv5HG1c4HeNDu57goC2cOWhKwFg+hWFT8zvfVfw7ewfO vopVfz4C4QgVKUwLIzlkC5sl4ucpI+RIrKwdP3Ruzy6Ne+w6eldLSEeg5RQzn6WTjeO1 XCkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708813270; x=1709418070; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0d0G2iv1lB/F5FVX2gdxbboYBMkYUC9mc/kMiOes1/E=; b=szj26dtjm4HUwG1MuQrQdTvvWPZF8rd2ERb4yYrHrZYX8pFYjvuGFBCQ1z3z7Pn/Nw oCJvIsQZgRWHPh5fQIEmyQt+OeUVuoKdjWtxnzdwD/vPM6x4NB58NvBQfd9JOgUJhHuH /h2Q7+cW3E7ZA95V7JMsmVNki0h5AqrdPFAWlrDKMqR3Ir3tgeSAAHbNzxLmKvIXCSws uB+hp9piAnV0rH8GQgI5x4Hjy+r/vg95+rfILItgbMVshO7oSyVF088xuHhqKIX3tBok xjHKcs8/dE+3ZPIWPS+oopeQmMWPr/vXLRF9jHw+JOFk5xPbb2OZcVsN/SL63B2ibIWw gbFA==
X-Forwarded-Encrypted: i=1; AJvYcCUxCAHE8qXHPcw+f92MHqqBTVrzYwpKiPBK0d0UxpMFJdMboZa1ZMHMb1P+zespuHuT3BZr+iZOdJiD1Zw2U2o9wHgrdNQajWZld97Qh4wa0qUgwQGgVlrxHpHNpGZZ4N2DxiTqwqtA9F7W0ZQ7fOP9fomVKr1XknFVYa7L83fZKQtCzyqyih2lY9A=
X-Gm-Message-State: AOJu0Yw4FF6mIRtDqaDuYqMD7+mPZjK/MxmNomofBe1fM+JBL4RDn/8X lzgAjysdwc2WnoC1s/979rvFDvVBsid5+oWO/gqsfET8iuOX2euR
X-Google-Smtp-Source: AGHT+IGkFDXH4CmjPcSPm74eZGm8Mdex5GMKCAHkBzFMORiI160iiioPngm3Xy3v8rVRyfSwfueLmw==
X-Received: by 2002:a05:6214:2b06:b0:68f:2eed:eac2 with SMTP id jx6-20020a0562142b0600b0068f2eedeac2mr2978696qvb.58.1708813269697; Sat, 24 Feb 2024 14:21:09 -0800 (PST)
Received: from smtpclient.apple ([136.54.28.118]) by smtp.gmail.com with ESMTPSA id z9-20020ad44149000000b0068d38023e35sm1108273qvp.112.2024.02.24.14.21.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Feb 2024 14:21:09 -0800 (PST)
From: Acee Lindem <acee.ietf@gmail.com>
Message-Id: <312A6132-E3B3-45CB-AAA9-C190C0C1B489@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3634943A-8680-4DD3-9528-DC94AFFA55DA"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\))
Date: Sat, 24 Feb 2024 17:20:58 -0500
In-Reply-To: <CA+RyBmXitJr-57P3y_=pYEqwoHeMo4HKqPKOud-ZZ2dQQb_gGQ@mail.gmail.com>
Cc: Joel Halpern <jmh@joelhalpern.com>, Routing Directorate <rtg-dir@ietf.org>, draft-ietf-mpls-p2mp-bfd.all@ietf.org, last-call <last-call@ietf.org>, mpls@ietf.org
To: Greg Mirsky <gregimirsky@gmail.com>
References: <170864700898.14065.4946299905740369098@ietfa.amsl.com> <CA+RyBmXitJr-57P3y_=pYEqwoHeMo4HKqPKOud-ZZ2dQQb_gGQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/8PtSkcvZJxrJo8mX0Kkh4MeCFcg>
Subject: Re: [RTG-DIR] [mpls] Rtgdir last call review of draft-ietf-mpls-p2mp-bfd-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Feb 2024 22:21:15 -0000


> 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