Re: [mpls] Rtgdir last call review of draft-ietf-mpls-p2mp-bfd-06
Greg Mirsky <gregimirsky@gmail.com> Sat, 24 February 2024 23:25 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 0F00BC14CEE3; Sat, 24 Feb 2024 15:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, 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 NHP3cSbNX38X; Sat, 24 Feb 2024 15:25:13 -0800 (PST)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 302CAC14F6FB; Sat, 24 Feb 2024 15:25:13 -0800 (PST)
Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-dc25e12cc63so1351537276.0; Sat, 24 Feb 2024 15:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708817112; x=1709421912; 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=ib2B0eu0AVGrBgiqG9aGOoHCNJi9KuP4kpKkbUhuDDY=; b=PIAeC1UEwk+DJY/y0NkdZFYiGp0LllLGhe8oGtMR1KOGzvy2ikbMqmb42ZSLQa8wE5 vubBvf+SZTmgnT6U4DALMSUzOis+mlSoz8MJf5H1SZr4LF9CmKiK/ffHoLnnaGVLbh9N +YrMO858JatU7hqyq8Nh2HsEjc8heoUyht4h3QZ1/MQBS5K9Jm/ZFjtJkHbBzZM8MwNH e5cA3xK1EYpWilmU3b1NX50W9IQL4KlrZoY8+CMbBgSz8RfEKPSkVnNM6HNbHl+rIqGh 7u2KZpjkAlZ7pq8gP0FSD74O2ZnfVVRIFlNo7HXdyBBk6vIsEGmuP1I7VIeQXo1wH6fJ jfJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708817112; x=1709421912; 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=ib2B0eu0AVGrBgiqG9aGOoHCNJi9KuP4kpKkbUhuDDY=; b=hKI26RbAfFWkzeYtkZCwt3mGtqwavVetTy3UZQIBGtk+S5+BkUdazafUNxQwXMQYMw XoyOLmtuYVo3qxsMKEumdruR4anZ3KB5jDZkCvLPXx9vN0IFKsxZGVe2PiHEslo+nytD QU19hUqelmeYkgrh+u+NLLEx5y13vfKAJ9JSYrTEpoNKZMt2nHoI4EKx+js5ChaaiB/D ZpKkqPVmLwk1l35zT6tzoA/+4GEOmweT/eYPVvCjQjvaamaRXrHQqDMfzlUjIz6PaqJx Q+jzDXw+IPyUepnpBs66vIwJaDqhMiwCcQp4bPZU1TeyuFD7hYM/oZkTxZ6vSHM4/N85 JzOw==
X-Forwarded-Encrypted: i=1; AJvYcCXeuJa/92rPmBJdwoOV6TdAHp3Qnrrf0K3fI606bz6Y+1r+n/M3DsDvYkImDRF8CAsBK9LqBQjj+j18UN/Ojpex2c3v9QtAUYOdpPUKAOlEBlJJW5jSa82RaEmI/s2v+XWWJDSqTfOdfX2NCABUEC6hsXXhvGxrXsw=
X-Gm-Message-State: AOJu0YwbpHa7pb94MKOdGMfbyUEnh7p5KFGeVaX/q8YZzabrOJYTNSb8 jHLS5rMn/BWJP/MK07y8TDr32hNVu0zHtZzT/2/+ocWIvMysaZvpI+/fs45dT96UMJ5/IQLk9u0 bcY53N7g6mneWPDcC5AcROoONyuFEhinY
X-Google-Smtp-Source: AGHT+IEGZIr1m0gFYoVPdjhNI1vZGvK3Qeud+6501FaqcjIz3OC0qZTa1j0mI0/5F4j6s/HmZsoxSBsfU0NKv/uM9pI=
X-Received: by 2002:a05:6902:1361:b0:dc6:cf8e:8f97 with SMTP id bt1-20020a056902136100b00dc6cf8e8f97mr2090298ybb.27.1708817112068; Sat, 24 Feb 2024 15:25:12 -0800 (PST)
MIME-Version: 1.0
References: <170864700898.14065.4946299905740369098@ietfa.amsl.com> <CA+RyBmXitJr-57P3y_=pYEqwoHeMo4HKqPKOud-ZZ2dQQb_gGQ@mail.gmail.com> <176e1397-5b01-487f-8ae0-078bfe2f8ee7@joelhalpern.com>
In-Reply-To: <176e1397-5b01-487f-8ae0-078bfe2f8ee7@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 24 Feb 2024 15:25:01 -0800
Message-ID: <CA+RyBmUMit0oc1MZTnQ0apTM8Wj_ra7Tna5JCwwMbtbKOfgyCQ@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="000000000000f37adf061228fc88"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-dJGwAGZB9K1yFe0eZHWVU0k9Dc>
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 23:25:14 -0000
Hi Joel, thank you for the clarification. My idea is to use a rate limiter at the root of the p2mp LSP that may receive notifications from the leaves affected by the failure. I imagine that the threshold of the rate limiter might be exceeded and the notifications will be discarded. As a result, some notifications will be processed by the headend of the p2mp BFD session later, as the tails transmit notifications periodically until the receive the BFD Control message with the Final flag set. Thus, we cannot avoid the congestion but mitigate the negative effect it might cause by extending the convergence. Does that make sense? Regards, Greg On Sat, Feb 24, 2024 at 2:39 PM Joel Halpern <jmh@joelhalpern.com> wrote: > That covers part of my concern. But.... A failure near the root means > that a lot of leaves will see failure, and they will all send notifications > converging on the root. Those notifications themselves, not just the final > messages, seem able to cause congestion. I am not sure what can be done > about it, but we aren't allowed to ignore it. > > Yours, > > Joel > On 2/24/2024 3:34 PM, 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: > 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. >> >> >>
- Re: [mpls] Rtgdir last call review of draft-ietf-… Loa Andersson
- [mpls] Rtgdir last call review of draft-ietf-mpls… Joel Halpern via Datatracker
- Re: [mpls] Rtgdir last call review of draft-ietf-… bruno.decraene
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… Acee Lindem
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… Joel Halpern
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… Joel Halpern
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… Joel Halpern
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] [RTG-DIR] Rtgdir last call review of d… loa
- Re: [mpls] Rtgdir last call review of draft-ietf-… Joel Halpern
- Re: [mpls] [RTG-DIR] Rtgdir last call review of d… Joel Halpern
- Re: [mpls] [Last-Call] [RTG-DIR] Rtgdir last call… loa
- Re: [mpls] Rtgdir last call review of draft-ietf-… loa
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… bruno.decraene
- Re: [mpls] Rtgdir last call review of draft-ietf-… loa
- Re: [mpls] Rtgdir last call review of draft-ietf-… bruno.decraene
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… Greg Mirsky
- Re: [mpls] Rtgdir last call review of draft-ietf-… bruno.decraene
- Re: [mpls] Rtgdir last call review of draft-ietf-… bruno.decraene
- Re: [mpls] Rtgdir last call review of draft-ietf-… bruno.decraene