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

Greg Mirsky <gregimirsky@gmail.com> Sat, 24 February 2024 20:35 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7897CC14F6A7; Sat, 24 Feb 2024 12:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 Dx14euCInugC; Sat, 24 Feb 2024 12:35:14 -0800 (PST)
Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) (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 47C55C14F6A6; Sat, 24 Feb 2024 12:35:05 -0800 (PST)
Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-608cba5507aso14784707b3.2; Sat, 24 Feb 2024 12:35:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708806904; x=1709411704; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=unnHsuswgYv0jZQPxerRyhTA6Susm7HgDdqujsZ8Z/o=; b=JO2FFaFzboMW/n9tEl1yWdabY5MQPriezgHEUngCRwb8r2+T1QeGkRBXUW2goPikue 7nBtOaGv/AoWuWn44OsQPRVm6TF/elD3Qsq4Gbqk4395GidXe/eZfkBeHj8ZadPnUFi5 EelBT3A9qY13cVANRv3rPHmo9WbfgKnl5PsO/m3UxUbPyWKB5UZdpTMuR3SozyTCkCNO aLSDeIuolAr1DSe9EPiaHxLOFZcI1p1qqlQFaPI6yaM+LrOrptHkKkSrIuiy8pOmF6t6 nbmdGtLovb7i3JV74Ue1jswERZYkaZMxg2HtnIO94EA0mRTqO2A0udUl3omPMiK1q8E8 yPjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708806904; x=1709411704; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=unnHsuswgYv0jZQPxerRyhTA6Susm7HgDdqujsZ8Z/o=; b=j3DrFlUUMPmEcHbJPmY3SHntIwt6BPGAnvdFhJdiNP3eG4+M80YGRKcZ4eFg+/XUAp KvMq+ep00gP266fGcCAXREAq8B/KOyI2lFsfoyNAgBpSgw2aip7J4G9QI08CE4JtEHy3 zXOugICKHdgeAAwJd+ZJRz91QcLnRLSCJomte8t2czAV/MgR2wnw4oJxFtQr/w2aN63n rcBak8YJi4iWXCtIzgQC5lwE3fGD+2Y851HBr/8e+OgxoQg8BEFoqUEP9TUCcqRMLOv2 fJv4wC3JmWbBiYqZTHfKm4Zk2Dl7aep7DqPocGWeiJqGyrI+Z9vAizkL1Sy2AItkXin7 wnww==
X-Forwarded-Encrypted: i=1; AJvYcCV/3sD+Mh+YGrlsM2OhbksjZ8xRaAe68XOf+ujAKr0R7TKvHBVPrbBuNP4svio/xCKmgyStkIU/uzZzOsaP5QKINcKptj0O+MQ7YMRxPCNz5tLSBdyjtnbkxes1oaaAjLxiyQxYxNHqGVJpWGavwMw05RdqRQZbtao=
X-Gm-Message-State: AOJu0YzNnnhwU3QHysfuvi0eQ3K6OaYKCECZDX6nef/nrRRLENVfElSJ 5qRylNMRuXHvn9mjaVeB9lA7OtXew8kAxU5nhBQnJ4aOe8GBs1n7ZbiFje38E4R6YAJiktU6IEc szH+m8n31r2+5H1fQKvrfXkNdk4ScGKDjOIY=
X-Google-Smtp-Source: AGHT+IF0C0S/Na6YkgKSqBrhpogenhSxBPhSMqHXtvRDUvaiz6Of38GPRQvcsa+kJa4dczgFAoZ6cnB+b7q3IsNoULE=
X-Received: by 2002:a81:e549:0:b0:608:bc78:94b7 with SMTP id c9-20020a81e549000000b00608bc7894b7mr2350838ywm.49.1708806904107; Sat, 24 Feb 2024 12:35:04 -0800 (PST)
MIME-Version: 1.0
References: <170864700898.14065.4946299905740369098@ietfa.amsl.com>
In-Reply-To: <170864700898.14065.4946299905740369098@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 24 Feb 2024 12:34:54 -0800
Message-ID: <CA+RyBmXitJr-57P3y_=pYEqwoHeMo4HKqPKOud-ZZ2dQQb_gGQ@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: rtg-dir@ietf.org, draft-ietf-mpls-p2mp-bfd.all@ietf.org, last-call@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008264520612269c89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ZakcUTKIVyC8WhDkz5yIrIvsIJc>
Subject: Re: [mpls] Rtgdir last call review of draft-ietf-mpls-p2mp-bfd-06
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Feb 2024 20:35:15 -0000

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