Re: [mpls] Rtgdir last call review of draft-ietf-mpls-p2mp-bfd-06
Greg Mirsky <gregimirsky@gmail.com> Mon, 26 February 2024 17:08 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 C7C83C151981; Mon, 26 Feb 2024 09:08:41 -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 r59X9gp-U3Zy; Mon, 26 Feb 2024 09:08:40 -0800 (PST)
Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 AFD1AC151539; Mon, 26 Feb 2024 09:08:40 -0800 (PST)
Received: by mail-yb1-xb29.google.com with SMTP id 3f1490d57ef6-dcbf82cdf05so3364719276.2; Mon, 26 Feb 2024 09:08:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708967319; x=1709572119; 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=pVcTmbk1bVeS6D+obPwCApXNBGLJACdkfKTX8ZmZSi0=; b=FHEnnHIMVgc7H1xvyRt4DYEZlRt1x/jHB+PLtqbrSmSOftS+iGKItQcqg4ERaUNVUy MeTcAXE1xESBBtqshiL1FLbI5dQnqE0QOJz2GsUPgLYplgtVRQCurkm27r+T74pJZncw cVf+cbjL5TCFIpz8/wAdKRmHt6KtBGi1VOK5JN97v7XQqvG8/4KSnveP8QmsSA7/6xuz CDiY+mkLe9xD3tufi6x1fJxKRsWdOKME4s4cFmkIl4P8BIVsJZH+4MhqlZmetJKtI7iC Ol0WnXUOxGxgeFhPhnOmvxfJo/oLqtJSsLWdz3ggtyews96nCq+B4cGTvLYYYIysNHyq FoiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708967319; x=1709572119; 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=pVcTmbk1bVeS6D+obPwCApXNBGLJACdkfKTX8ZmZSi0=; b=OUUqewtW/5idghO/sTAH9hO2oBKoh1ND6/tJJ19hDWlrcN7Was5h9CIlwBI08ajzxz iuXuLxJZDzChzOIGMgf3gc7iHzqLcrLAB4N7mMhRONlpTGJJinuOF/OvXwUtAUb8kAaD RgJpHz9IiY6l/xZxnEnRKKNod4gnvlB0KCcxLCx39tOZuNgYpDKWJYne00TJD44btrq1 BoPY4bDYVKDDsa9qU4PfPvo/UG/kEX+TIS93jCsWKggHKFcMRJ7iz/T1qZ4fWNG5Hxuw kRj91250zm1xguwcgd0ZAaMrK3wdUaMX3qZxiqm6vOVdfdw5ez3iZ/iGmTfh8f3SISmf VE4g==
X-Forwarded-Encrypted: i=1; AJvYcCV9HXlzxf4fBWU5Rf0Ha9P8iaIx7zPo6qaA4q1zVgE230A5B6RWKwsBhVfa+PdCVemqrHTLCk1lf6SBbhMxPul3Lq4yaygSXt6zwUjFjv2fxxev2Mr9jnU+jdUVIgPyrXMtLrrm4jrZtqrcVfV4SFxemoLGbReDIMyuGfyqAvzHDU0iZZVIz8TGM0k=
X-Gm-Message-State: AOJu0YxpA449eoGYQG6xtX24mpKpKSKZC0N8UqR0XbtGmYL5d+SnueAJ QqjPPiTS47lUHx76R4anUSUBxQx/s2w62ZM2BjnwK/8fLmJ7LLwc7cmy4dXDXQCmV6O56IMKNxO 4Yo8/SF1hEMa0tWtN/uOJj8crtaM=
X-Google-Smtp-Source: AGHT+IGzI9lH4v3p8XC3l4k9NaklrSxFJupXDlaEGH8nWQCQJ3uq8TV7YT1RCwPbYdauzzLXB4UnkgBakheUoIpjw/Q=
X-Received: by 2002:a25:e301:0:b0:dc6:9daf:35c7 with SMTP id z1-20020a25e301000000b00dc69daf35c7mr5406058ybd.28.1708967317980; Mon, 26 Feb 2024 09:08:37 -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> <CA+RyBmUMit0oc1MZTnQ0apTM8Wj_ra7Tna5JCwwMbtbKOfgyCQ@mail.gmail.com> <AS2PR02MB8839697CBBD90B7E98B65C38F05A2@AS2PR02MB8839.eurprd02.prod.outlook.com> <49c3fc046a39a0aadda2309f84c14436.squirrel@pi.nu>
In-Reply-To: <49c3fc046a39a0aadda2309f84c14436.squirrel@pi.nu>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 26 Feb 2024 09:08:28 -0800
Message-ID: <CA+RyBmXKJ4v2oMaGhbC19ar5VTcbHkTSo+APBgiw7kG4k4m9PA@mail.gmail.com>
To: loa@pi.nu
Cc: bruno.decraene@orange.com, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-p2mp-bfd.all@ietf.org" <draft-ietf-mpls-p2mp-bfd.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebc9cb06124bf592"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/ZOk038eHJV1maQHDv_ojHT_jbCg>
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: Mon, 26 Feb 2024 17:08:41 -0000
Hi Loa, thank you for suggesting a mechanism that can minimize manual configuration. It lead me to look at the mechanism defined in RFC 5880: The periodic transmission of BFD Control packets MUST be jittered on a per-packet basis by up to 25%, that is, the interval MUST be reduced by a random value of 0 to 25%, in order to avoid self- synchronization with other systems on the same subnetwork. Thus, the average interval between packets will be roughly 12.5% less than that negotiated. I think that might be helpful adding it, or similar, to the action of a leave that detects the failure. Regards, Greg On Mon, Feb 26, 2024 at 3:54 AM <loa@pi.nu> wrote: > Bruno, > > I'm not responding for Greg, I guess he will respond for himself soon. > > What you describe is very attractive and I think it will be implemented. > > However, I think that what Greg was looking for was something that > wouldn't need to configured. > > /Loa > > > Hi Greg, > > > > My 2 cents (not following the draft). > > Another typical option may be to allow the network operator to configure, > > on the egress, an acceptable delay before reporting to the root. The > > egress would then pick a random value in this range. Statically, the more > > egress the more spread the reports to the root, which a priori would be > > good for scaling. > > It would be up to the network operator to configure the right delay > > depending on the number of the leaves and the need for fast reporting (or > > not). > > > > Totally up to you, but that would have my vote as this is a typical > issue. > > (granted this is more likely an issue with protocols handling thousands > of > > customers, but even for MPLS LSR scaling, RSVP-TE scaling issues are not > > unheard) > > > > Regards, > > --Bruno > > > > From: mpls <mpls-bounces@ietf.org> On Behalf Of Greg Mirsky > > Sent: Sunday, February 25, 2024 12:25 AM > > 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 > > Subject: Re: [mpls] Rtgdir last call review of > > draft-ietf-mpls-p2mp-bfd-06 > > > > 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<mailto: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<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. > > > > > ____________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > > recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme > ou > > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been > > modified, changed or falsified. > > Thank you. > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > > >
- [mpls] Rtgdir last call review of draft-ietf-mpls… Joel Halpern via Datatracker
- 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-… bruno.decraene
- 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-… Loa Andersson
- 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