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

Jeffrey Haas <jhaas@pfrc.org> Fri, 25 February 2022 22:05 UTC

Return-Path: <jhaas@slice.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 AB0D43A0A36 for <idr@ietfa.amsl.com>; Fri, 25 Feb 2022 14:05:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 2g6r6cNXHxsL for <idr@ietfa.amsl.com>; Fri, 25 Feb 2022 14:05:14 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6596D3A0A26 for <idr@ietf.org>; Fri, 25 Feb 2022 14:05:14 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id AAAF31E345; Fri, 25 Feb 2022 17:05:13 -0500 (EST)
Date: Fri, 25 Feb 2022 17:05:13 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Wei Wang <weiwang94@foxmail.com>
Cc: idr <idr@ietf.org>
Message-ID: <20220225220513.GF452@pfrc.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> <tencent_03B5E7EB25CDCDCC0FB121678E45FDB4C10A@qq.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <tencent_03B5E7EB25CDCDCC0FB121678E45FDB4C10A@qq.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uoQO8vqSA82UCrfXppFjwNbMg1A>
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: Fri, 25 Feb 2022 22:05:17 -0000

Wei,

On Fri, Feb 25, 2022 at 02:26:37PM +0800, Wei Wang wrote:
>    Thanks for your valuable suggestions and scene refinement, we think the following principles can be applied to the drop strategies:
> 
> when a <RD, source PE> tuple past the "fair" ratio but the prefix limit of VRF is not exceeded, PE should send warnings to the operator, and the drop strategies should not be triggered.
> 
> when a <RD, source PE> tuple past the "fair" ratio and the prefix limit is exceeded and there is no other VRFs on offended PE need VPN routes with this RD, they should be dropped.
>    The above strategies is only an example, there may exist other algorithms to be explored further and should be researched in another document in details. The operators just need to make sure the algorithms in different devices consistent. 
> 
>    If you agree with the above strategies, we will update our draft accordingly to reflect them. 

If this is your general intent for how the feature works, I think many of
the participants in the thread would appreciate such discussion becoming
part of your proposal.

Further discussion below:

>    For our considerations on the use of the principles in your mentioned scenarios, please see in-line replies with [WW].
> 
[...]

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

[...]

> 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.
> [WW] After RD-4 past the "fair" ratio, router should send warnings to operators for further adjustment. If the prefix limit of VRF-A is exceeded and RD-4 still past the "fair", router will drop RD-4.

For this example, your intention is clear.

> 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?
> [WW] If RD-1 and RD-2 still past the "fair" when utilization is higher than 100%, router should drop them both.

This is also clear.

> 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.
> [WW] If we do nothing, the offending VPN routes may influence the communication among VPNs and the communication between PE and the router outside of the VPN. If we filter the route from the access router outside of the VPN, only the latter communication will be influenced. 

I understand your point, but believe we have different scenarios in mind
that impact the outcome.  That's fine.  I believe you understand my point
that dropping the largest may sometimes have negative impact to overall VPN
operations.  Your choice is that the negative impact of the excess routes is
more important.

-----

I want to add one final point to the scenarios I have been using for
discussion.  These examples all use a fixed number of RDs for the 1/N ratio.

For "fair" to be able to be determined, it would be necessary to know the
total number of expected RDs present at a given PE for a given VRF.  This is
effectively a form of per-RD-per-VRF prefix limit.

If you agree that this is per-RD-per-VRF prefix limit as configuration
state, I believe you now have a point of clarity you can add to your
proposal that defines its expected operation.  This permits more flexibility
than 1/N fairness where N is unknown.

-- Jeff