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

Acee Lindem <> Sat, 24 February 2024 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 295E6C14F5FB; Sat, 24 Feb 2024 14:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Evr1rgxxEm2l; Sat, 24 Feb 2024 14:21:11 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 38B89C14EB17; Sat, 24 Feb 2024 14:21:11 -0800 (PST)
Received: by 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;; s=20230601; t=1708813270; x=1709418070;; 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;; 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 ([]) by with ESMTPSA id z9-20020ad44149000000b0068d38023e35sm1108273qvp.112.2024. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Feb 2024 14:21:09 -0800 (PST)
From: Acee Lindem <>
Message-Id: <>
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: <>
Cc: Joel Halpern <>, Routing Directorate <>,, last-call <>,
To: Greg Mirsky <>
References: <> <>
X-Mailer: Apple Mail (2.3774.300.61.1.2)
Archived-At: <>
Subject: Re: [RTG-DIR] [mpls] Rtgdir last call review of draft-ietf-mpls-p2mp-bfd-06
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Feb 2024 22:21:15 -0000

> On Feb 24, 2024, at 15:34, 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:
>    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.
>    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./ 

> Regards,
> Greg
> On Thu, Feb 22, 2024 at 4:10 PM Joel Halpern via Datatracker < <>> 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
>> 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