IETF Logo Mail Archive

Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

Jeffrey Haas <jhaas@pfrc.org> Mon, 29 August 2022 12:45 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD273C15259A for <idr@ietfa.amsl.com>; Mon, 29 Aug 2022 05:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 vxo2-3dj9Phf for <idr@ietfa.amsl.com>; Mon, 29 Aug 2022 05:45:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AF6E8C15259B for <idr@ietf.org>; Mon, 29 Aug 2022 05:45:54 -0700 (PDT)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id 772A01E31E; Mon, 29 Aug 2022 08:45:53 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <CAEfhRrz5aAJmy2Ye1gqss2d72nm78n4SfeowO-FU7i4Z6Zpb+A@mail.gmail.com>
Date: Mon, 29 Aug 2022 08:45:52 -0400
Cc: Wei Wang <weiwang94@foxmail.com>, idr <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CD78D4C-672F-41AA-8E1B-98CD8A875D21@pfrc.org>
References: <tencent_3C3279A3B4DAF8DA03F446E7AAE799D8AA09@qq.com> <CAEfhRrz5aAJmy2Ye1gqss2d72nm78n4SfeowO-FU7i4Z6Zpb+A@mail.gmail.com>
To: Igor Malyushkin <gmalyushkin@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lPtyjyFRxX3N0zi8XexoSStF6t4>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2022 12:45:57 -0000

Igor,

> On Aug 29, 2022, at 8:39 AM, Igor Malyushkin <gmalyushkin@gmail.com> wrote:
> 
> 
> In the first option, will RR withdraw all PE3`s routes until the number of these routes reaches to the quota of PE3, right? In such way, the described problem can happen only in the second scenario because there will be a room for the routes of PE2. If RR withdraws routes that overflowed the VRF prefix limit only, the described problem will actual for any case.

One observation is that the local systems, when examining their quotas, can use the fact that it knows that a given RD is intended to be mitigated by the ORF or not.

Exactly how the system needs to behave in the implementation would partially depend on the reason for mitigation.  For memory exhaustion, it may need to be more aggressive about discarding routes.  For CPU overload, lesser mitigations may be sufficient.

I think the critical implementation detail is that once this ORF is triggered, it should require operator intervention to clear to avoid thrashing routes.

-- Jeff

v2.23.0 | Report a Bug | By Email