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

Wei Wang <weiwang94@foxmail.com> Wed, 31 August 2022 13:03 UTC

Return-Path: <weiwang94@foxmail.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 E71ADC1522C9 for <idr@ietfa.amsl.com>; Wed, 31 Aug 2022 06:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.92
X-Spam-Level:
X-Spam-Status: No, score=-3.92 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, 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 (1024-bit key) header.d=foxmail.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 dZbuKY1dVc5h for <idr@ietfa.amsl.com>; Wed, 31 Aug 2022 06:02:59 -0700 (PDT)
Received: from out203-205-221-192.mail.qq.com (out203-205-221-192.mail.qq.com [203.205.221.192]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D72C1524AC for <idr@ietf.org>; Wed, 31 Aug 2022 06:02:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1661950971; bh=h9ZvOFqDwT1md6mltjsnaL7tBKEvRgXHvCMMKncKzug=; h=In-Reply-To:References:From:To:Cc:Subject:Date; b=EB5QHjLta+DIN+rhlQZyrs++oUH/f7Pmz0q7fnlSeanDGZOP4txfICnfjitVbvXdg 8mCPdcvDau0oEeFDELYoJcGXEfc0cPb3ufcET46ogL1V3CcILH0gbSTD4sUWp1/Lyc DLHKQZioWfP2ZGOBdvmjbgofiPfOZGko0OHELW1g=
X-QQ-FEAT: oHWrrGTW1dCGJEu1CuC8+nIWkvSYK6n9
X-QQ-SSF: 00000000000000F0000000000000
X-QQ-XMAILINFO: MDPfhejMR4aIj1zGFqneGFRnjHpxDjNcAunBXCD9nt5aKqk695qQHTkNEbuoMZ 3naqeLn8oolRihVJ1pEk9Is1XLi3Ls5SQHEmL+T3ypaBppt38OZoF8vGdkD3hKKrvkD/T3VRANYN0 haVi5ZsScLAvgbNyJqfPTf87cMXj6DKqXxpJPPyFgN+SgBtBTUuuHtIPOfXeFWar50zkX26ELRJZh a5FML5IfYbzPee+SGurXXHv0tY0jDnmPiAMfEhu7gh8RdcU8a8grlgSUq1glzi18vfJX+3FzlGso+ YDAE42ewX0omQDcwjB2O2sf8QXnJXBudI/PqgML874cfw1rWmLT1xv/9j5pPGW2XFmj6eGw5wf+sq s7XAxGesFt6Bf+4IWxldyGjqSPSKccOWWQw/g3VbnnM+BiPrlVNLlMpGVjIV7YaMEcuPF1cVrcsUz HjuyqAKQmAlT94tHk5eJpfbaQnI4eSVND86qXXteQXqvApAg4hcKBfwpR50Puar7iKVcVMT2HyDAR 13mPfvqRdJnQTRNlDX8r5NuLmM2Qm5SjavCVfSJEjTT0SUYBM4+0KUTAEIO848Xpvb4EIa2KlILDh BZSrZuS9OVQIT0pqqXRnVnz8kl7HC5m/bFtDUZv5oEcca8xY7IV1CngGo5MpncadnEmT+hF37w0Yl i1k4HtufC2nP3/Ze8BdzGNuQGfjY0I2rmR0xZIPOvoz1xb6lbw+kmjbjvpxEtQj4hoAKZs3XgmnUX P96MTB7YjXv5AmyNRo9nJhnZsGA1p3k9r+3vpBGDyiRTLvkkA0u6b0s6daWrHIHnCQrWMY3U7pwDh Ys4wLyYNmiY+Sirldb3ieL13AdYvwEzpADaEWT3YsYZPyR2QcTP9PBt7cW8VV7woDHyOPBWDnfg59 h72uGIZmGtD2Cn8Cw8Nh+SgVZCaXjscd6qBJsmkjUSzrgMdZ2DMTgedPQUNA4j6DDSToEUvDwStyv ekDivcUYN+vnmF0ojD8I4bUO1mtRb//25m/FpPQ9f09SUSpSHNzwfIwaeBIH4KhUVZQtfrpijLYnf W74PPwtBVvNmqlFg8o0T6MRF3Nw==
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-Originating-IP: 106.120.219.179
In-Reply-To: <CAEfhRrwUYOUmZuaPhdF8m92iedRYeXaEpSXhUTTT5UmXFDyHqA@mail.gmail.com>
References: <20220831072731.5F2309000AF@hmail-m121149.qiye.163.com> <E413E79B-A819-48AE-9014-BDCF77ADA2EA@tsinghua.org.cn> <CAOj+MMHsNnnvhh=WZP6cw4LZY5PTy727uy3jsHqgnXfbN1R-uA@mail.gmail.com> <CAEfhRrwUYOUmZuaPhdF8m92iedRYeXaEpSXhUTTT5UmXFDyHqA@mail.gmail.com>
X-QQ-STYLE:
X-QQ-mid: webmail812t1661950971t6107403
From: Wei Wang <weiwang94@foxmail.com>
To: Igor Malyushkin <gmalyushkin@gmail.com>
Cc: idr <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_630F5BFA_10AE6DC8_21BD5ED4"
Content-Transfer-Encoding: 8bit
Date: Wed, 31 Aug 2022 21:02:50 +0800
X-Priority: 3
Message-ID: <tencent_2EF9A30EDA26DA25F5F2E6E4E71DD81C3209@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fjmJzN56MFOALgN-OMGlpzGysTQ>
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: Wed, 31 Aug 2022 13:03:03 -0000

Hi All,


&nbsp;&nbsp;&nbsp; The updated draft is the fruit of previous intense discussions, we have analyzed various possible situations. Let me explain some major concerns again:


1) About the quota:
&nbsp;&nbsp; Actually, the quota is not exist in the original version, but we found there are some problems during the discussions in the mailing list. So, we add the quota to improve the drop strategies after the VPN Prefix ORF mechanism is triggered. We can't drop all the routes(from all sources) belong to the VPNs when the VRF limit is exceed because one of the rogue PE.
&nbsp;&nbsp;&nbsp; The reason that quota is set for every PE is that in real network the number of customer routes in each VPN under different PEs may be different. So, the quota value should be set depend on the customer scale.
&nbsp;&nbsp; For more information about quota, I think you can refer the discussion: https://mailarchive.ietf.org/arch/msg/idr/uoQO8vqSA82UCrfXppFjwNbMg1A/


2) About the proposal for sending the ORF message directly to the source:
&nbsp;&nbsp; I think scenario-1 and scenario-2 in the updated draft (https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf#section-4.1) have described the cases that it is not approciated to stop the source advertisement directly based on the VPN Prefixes ORF message from only one PE. There may be other complex scenarios.
&nbsp;&nbsp; And on the other hand, the VPN Prefixes ORF message is triggered when the Quota and VRF limit threshold are both exceeded. It is possible that the Quota on all PEs is same, but the VRF limits are different. Then the weak PE may first trigger the VPN Prefixes ORF message, but the other PE can still receive some amounts of excessive routes. In such case, VPN Prefixes ORF message should not be sent directly to the source.



And please also see my reply to Igor's concern inline with [WW].



Best Regards
Wei


------------------&nbsp;Original&nbsp;------------------
From:                                                                                                                        "Igor Malyushkin"                                                                                    <gmalyushkin@gmail.com&gt;;
Date:&nbsp;Wed, Aug 31, 2022 05:49 PM
To:&nbsp;"Robert Raszuk"<robert@raszuk.net&gt;;
Cc:&nbsp;"idr"<idr@ietf.org&gt;;"John E Drake"<jdrake=40juniper.net@dmarc.ietf.org&gt;;"Sue Hares"<shares@ndzh.com&gt;;
Subject:&nbsp;Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)



Hi all,

I agree with Robert and John, I`ve expressed concerns about quotas several times on this list. This construction is overcomplicated and unnecessary, IMO. I know the authors` intention is to make things better in a case of a VRF overflowing, but I want to point them to the fact that this case is exceptional by the definition. We don`t face this problem on a daily basis. When it happens human intervention is still required in any case. Thus, I think we should concentrate our attention on the crux of the problem.

As I also said, I agree that we don`t need to receive routes in the case a VRF is overflowed. We cannot exclude from the consideration the claims when several PEs are "rogue" at the same time, so a destination PE needs to process several&nbsp;groups of UPDATEs, then send ORF for every source, then process UPDATEs with withdrawals. Multihoming is just one case from this class. I believe it`s possible just to stop all UPDATEs for a VPN at the same time (which the authors partially approved for the multihoming case). Thus, we enhance a local VRF prefix limit&nbsp;feature&nbsp;without needing quotas, source identification, and the rest of the complexity. I suggested the authors include this option in the draft so implementors can decide which approach is appropriate. Their favorite vendor can implement the draft with quotas, others can do it too or not. This is not prone to interop problems if it is inscribed well in the document.

Quotas are not only complex from the operational point of view. Although, this is also important and frustrating. I still don`t agree that we need to delete some routes from a VRF. Let`s imagine we have a quota for router A on router B`s VRF of 100 routes, also there is a VRF prefix limit of 200 routes. At T1 we receive 100 routes from A, all of them are under the quota and are valid. At T2, we receive extra routes from the A, say, 99 routes. Router B warns ops via a logging system, but are these routes excessive? Router B doesn`t send an ORF message because the VRF prefix limit is not reached. At T3 we have 199 routes from the A in the VRF and receive another group of 2 routes from the A. Now we`ve reached the limit. Router B sends the ORF message and asks RR to withdraw of 101 route. But why? Why do these 2 routes make the previous 99 excessive? This logic is not straightforward to me.&nbsp;
[WW] Theoretically, B can keep A’s routes that pass the quota(99 in your example) for a short time even it exceeds the VRF limit(200), until there are other routes coming from other source. But such design will make the implementation more complex: B needs to calculate whether the excessive routes from the original source or new source.
Actually, A has occupied the extra resources(99 routes)for some time, it is time to release the source they occupied when the VRF limit is exceeded, to leave space for routes from other sources.
The overall principle is that the system has some tolerances until they cross the predefined criteria.


Either don`t install routes over a quota or don`t delete them after it. Even if we stay it in the draft future implementations won`t be easy to understand by people.

My 2 cents.

ср, 31 авг. 2022 г. в 08:46, Robert Raszuk <robert@raszuk.net&gt;:

Dear&nbsp;Aijun,

Sorry but I simply can't resist it ...&nbsp;



On Wed, Aug 31, 2022 at 1:54 AM Aijun Wang <wangaijun@tsinghua.org.cn&gt; wrote:

Hi, John:

Glad to hear your concerns. Let me explain them to you:
1) There are various reasons that the receiving PE is overflowed by the excessive VPN routes. For example, the capabilities of PEs within the network are different, we can’t block the source directly just solely based on the request from one PE. 





What you just stated above is simply the wrong thing to do in fact irrespective where the drop of the routes would take place in the&nbsp;network.&nbsp;


If capacity of any PE does not permit serving given VPN such VPN should not be provisioned on such PE.&nbsp;


Adding protocol extensions to address provisioning mistakes (not accidental as stated above but well thought onboarding&nbsp;of a VPN to a network) and in the same time partially breaking connectivity within subject VPNs should not be endorsed by any IETF WG.&nbsp;


In fact what you have stated above is a clear proof that we do not even have a well defined problem statement. All we have is a solution which here and there in the network breaks VPN connectivity.&nbsp;




&gt; 2) For the quota setting, actually, the operator need only the per PE resource allocation under one VRF, and in most of&nbsp;
&gt; the situations, such per PE allocation will be same for one VPN in every PE



You mean under each VRF on each PE.&nbsp;


And please explain how that new number should be different from today's VRF prefix limit ? Why there is need to introduce new limit?&nbsp;


Thx,
R.
 
  
 
 
 
  
 
 
 
 




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