Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

Susan Hares <shares@ndzh.com> Tue, 01 March 2022 19:57 UTC

Return-Path: <shares@ndzh.com>
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 76FCB3A0BCB for <idr@ietfa.amsl.com>; Tue, 1 Mar 2022 11:57:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.125
X-Spam-Level: *
X-Spam-Status: No, score=1.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkZyjtdrlAyE for <idr@ietfa.amsl.com>; Tue, 1 Mar 2022 11:57:54 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6F13A0C5F for <idr@ietf.org>; Tue, 1 Mar 2022 11:57:54 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.107.120.176;
From: Susan Hares <shares@ndzh.com>
To: 'Robert Raszuk' <robert@raszuk.net>, 'Jeffrey Haas' <jhaas@pfrc.org>
Cc: "'idr@ietf. org'" <idr@ietf.org>
References: <E5BFF2D4-1ABC-40EF-912C-3AE0B7913E87@pfrc.org> <33DCDB50-1199-4836-BCE1-96FC65D9841C@tsinghua.org.cn> <1010520a-6e3e-4090-73db-d4b85114069e@foobar.org> <00cc01d82925$6a4dec10$3ee9c430$@tsinghua.org.cn> <5e1f327f-4671-843c-6f9a-26d7abbba16c@foobar.org> <20220224153110.GA27850@pfrc.org> <CAOj+MMFJqbUSws0UYXtgtS-QLm4S1o41pkZgLNac3b-1CLYJbQ@mail.gmail.com>
In-Reply-To: <CAOj+MMFJqbUSws0UYXtgtS-QLm4S1o41pkZgLNac3b-1CLYJbQ@mail.gmail.com>
Date: Tue, 01 Mar 2022 14:57:47 -0500
Message-ID: <001901d82da6$a03ad1a0$e0b074e0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01D82D7C.B76788C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJWUhk2r2jWi3MzTSf6F1aefrdruwIUMVbvAVTQPt4BvQKStQMZ8J+/AgZSDKECVqNPrKtJwGlA
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ya8GeStLvGOXRHaLg7ca30MgLTw>
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 01 Mar 2022 19:58:00 -0000

Robert: 

 

This is a specific answer to your question about why the discussion for this draft is going on in IDR. 

 

Why is it in IDR:  1st The draft proposed a new ORF function.   

 

I am not re-opening this adoption call.  I am still walking through the energetic discussion over the last 2 weeks. 

 

Sue 

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, February 24, 2022 10:52 AM
To: Jeffrey Haas
Cc: idr@ietf. org
Subject: Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

 

Hi Jeff,

 

> The proposal seems to simply choose the RD that has the highest 

> number of contributing routes.

 

That is not clearly stated. 

 

Authors seem to also indicate to drop the last ones which exceeded the limit in some of the messages irrespective to the percentage src RD contribute to the threshold. 

 

Moreover it also needs to be noticed that such drop (especially remote) does not apply when given arriving route is imported to some other VRF and there it does not cross the limit. 

 

- - - 

 

I think the first question to ask to the WG is if partial and random connectivity better then no connectivity for a given VPN. IMO no connectivity is much healthier. 

 

If we converge on this then we could think about next steps. But then again if we are taking about VPNs is this IDR topic or BESS topic ? 

 

Thx,

R.

 

 

 

 

 

 

On Thu, Feb 24, 2022 at 4:31 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

On Thu, Feb 24, 2022 at 11:45:23AM +0000, Nick Hilliard wrote:
> Taking your last statement first:
> 
> > Then, we can say the offending VRF is in bad behavior, right?
> 
> No, a specific party connected to a VRF is the malicious actor. Please
> remember that multiple parties may connect to a single VRF.  If
> there are other parties connected to the same VRF on the same PE,
> then the attack vector is substantially the same.

It might be helpful to build some less abstract examples.

Presume the VRF has statistics about its contributing routes, minimally
per-RD.  Let's say that there are N RDs in the VRF.

The challenge for drop strategies for oversubscribed resources is how you
decide what the drop criteria are.  One example strategy is fair allocation.

If there are N RD in the VRF, one strategy is each RD can keep 
prefix-limit/N routes each.  Effectively this is a per-RD prefix-limit.
This strategy only works well if each RD contributes a similar number of
routes.

When each RD may contribute different numbers of routes, 1/N of the resources
doesn't utilize the system efficiently.  What drop strategies can you use
for unequal distributions?

The proposal seems to simply choose the RD that has the highest number of
contributing routes.  When this is intended to mitigate a highly asymmetric
set of inputs, the choice seems easy.  RD-bad bursts to a number of
contributing routes significantly larger than the other contributors, like
receiving the full Internet table when we're expecting a small number of
routes.

Less extreme cases are not as clear.

Consider a router has a VRF-A that has an overall prefix-limit of 100
routes.  Consider that there are 4 contributing RDs.  A fair strategy would
be each RD can contribute 25 routes without penalty.

Setup:
RD-1, RD-2, RD-3: 10 routes
RD-4: 40 routes.

Utilization at start of scenario, 70%.  RD-4 is past the "fair" ratio, but
oversubscription is permitted.

Scenario 1: RD-4 increases to 80 routes.

In this circumstance, RD-4 is clearly "unfair" to RD-1, RD-2, RD-3.
Dropping RD-4 seems obvious.  This seems to match discussion from the
proposal authors to date.

Scenario 2: RD-1, RD-2, RD-3 increase to 25 routes each.
The load on the system is now at 155 routes.  RD-1, RD-2, RD-3 are still
using the theoretical fair share.  Do we drop RD-4?  I believe this is what
the proposal suggests.

Is this fair to RD-4?  They were previously permitted to burst past the fair
share and changed nothing.  RD-4 may have been operating stably at that
level for a while.

Scenario 3, different setup:
RD-1, RD-2: 26 routes
RD-3: 25 routes
RD-4: 10 routes

Utilization at start of scenario: 87%

We see that RD-1 and RD2 are past "fair" and RD-3 is at "fair".

RD-4 increases to 24 routes, less than "their fair share".  Utilization is
now at 101%.  Who do we drop?  RD-1?  RD-2?

The above scenario is an example of natural routing growth "squeeze" we tend
to see in the deployment of prefix limits.  If your threshold is too low,
natural growth or route churn within what should be acceptable tolerances
can lead to exceeding a limit.  For these reasons, implementations often
have "warn" limits and limits that have harder actions including dropping
peering sessions or discarding routes.

It should also be clear that the contrived examples above get much more
complex when we deal with the real world.  Whether route contribution per-RD
is uniform or highly asymmetrical depends on the deployment.  Sometimes the
contributor of the most distinct routes per-RD is the most important router;
e.g. the access router outside of the VPN.  This can lead to an outage for
the VPN.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr