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

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 30 August 2022 14:51 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
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 CC8B0C15A729 for <idr@ietfa.amsl.com>; Tue, 30 Aug 2022 07:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level:
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 s4PThrOVfjwP for <idr@ietfa.amsl.com>; Tue, 30 Aug 2022 07:51:08 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2E3C14CF1F for <idr@ietf.org>; Tue, 30 Aug 2022 07:51:05 -0700 (PDT)
Received: from smtpclient.apple (unknown [221.223.103.237]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 1BDF68000E7; Tue, 30 Aug 2022 22:50:58 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-19F90933-5F4C-47A0-86B4-9850F9EFED78"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
In-Reply-To: <BY3PR05MB80812C92380A7C25A46FA97AC7799@BY3PR05MB8081.namprd05.prod.outlook.com>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Robert Raszuk <robert@raszuk.net>, idr <idr@ietf.org>, Sue Hares <shares@ndzh.com>
Date: Tue, 30 Aug 2022 22:50:57 +0800
Message-Id: <475305E2-2F1D-479D-8E95-B3EAFC4D8EE2@tsinghua.org.cn>
References: <BY3PR05MB80812C92380A7C25A46FA97AC7799@BY3PR05MB8081.namprd05.prod.outlook.com>
To: John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
X-Mailer: iPhone Mail (19G82)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkZHUlMVhpPHx5OTEhPSx0aSVUTARMWGhIXJB QOD1lXWRgSC1lBWUlJSlVJSUhVSktIVUlITFlXWRYaDxIVHRRZQVlPS0hVSkpLSE1KVUpLS1kG
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6ORw6Sjo6Tj0rTkgMNQEoCxAO LjkwCytVSlVKTU1KQ0xKS05DTkNNVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSFVJSExZV1kIAVlBSUlMTEs3Bg++
X-HM-Tid: 0a82ef3beccab03akuuu1bdf68000e7
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RoAT-zDbUrHm8gzzQJcXkam5N9Y>
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: Tue, 30 Aug 2022 14:51:12 -0000

Hi, John:

I think you can discuss Robert’s approach within BESS from the scratch.

I think you should know the VPN Prefixes ORF mechanism has been analyzed throughly within the IDR, the updated draft has incorporated many comments/suggestions that the IDR experts provides.
It is now the solid base to solve the problem and we have also analyzed other possible approaches, which have been also discussed within IDR intensely.

So, if you are also interested this topic, I think you can start the journey at the BESS. We are glad to hear your comments for VPN Prefixes ORF solution within IDR WG.

Aijun Wang
China Telecom

> On Aug 30, 2022, at 22:13, John E Drake <jdrake=40juniper.net@dmarc.ietf.org> wrote:
> 
> Hi,
>  
> I think Robert’s approach is a much better solution to the problem and it obviates the need for the subject draft.  As an aside, why isn’t this topic being discussed in bess rather than idr?
>  
> Yours Irrespectively,
>  
> John
>  
>  
> Juniper Business Use Only
> From: Idr <idr-bounces@ietf.org> On Behalf Of Gyan Mishra
> Sent: Tuesday, August 30, 2022 9:56 AM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: idr <idr@ietf.org>; Sue Hares <shares@ndzh.com>
> Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>  
> [External Email. Be cautious of content]
>  
>  
> Hi Robert 
>  
> We would like to hear your thoughts on ORF towards source PE.  
>  
> I do agree that would help stop the problem at the source which we can add to the overall solution.
>  
> Kind Regards 
>  
> Gyan
> On Tue, Aug 30, 2022 at 4:49 AM Robert Raszuk <robert@raszuk.net> wrote:
>  
> To close this discussion I do not agree at all with neither point #1 or #2 in your reply below. 
>  
> And from RR I was not proposing RTC but ORF to src PE. 
>  
> But since you are not willing to discuss any alternatives further emails are pointless. 
>  
> Kind regards,
> Robert
>  
>  
> On Tue, Aug 30, 2022 at 5:01 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> Hi, Robert:
>  
> Regarding to your “final question”, my answers are the followings (I think you are mentioning again the RTC based approach):
> 1.     The overflowed VPN routes can only be identified/triggered via the receiving/overwhelmed PE.
> 
> 2.     The per RT based maximum number of routes on RR can’t represent per VRF limit on the receivers.
> 
>  
> Finally, thanks for your comments and suggestions during the adoption call of this draft, the updated draft has already incorporated some of your constructive suggestions, and we are glad to hear more such kind comments later. We have discussed intensely other possible approaches, there is no easier way to achieve such goal. 
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: Robert Raszuk <robert@raszuk.net> 
> Sent: Tuesday, August 30, 2022 12:24 AM
> To: Igor Malyushkin <gmalyushkin@gmail.com>
> Cc: Aijun Wang <wangaijun@tsinghua.org.cn>; idr <idr@ietf.org>; Sue Hares <shares@ndzh.com>
> Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>  
>  
> Hi Authors of this document, 
>  
> I have final question to you on this proposal. 
>  
> Would you be willing to rewrite the draft such that the required behaviour and protection can be run on Route Reflectors and not on receiving PEs ? 
>  
> That way one hop ORF will easily reach the src PEs and the fire can be locally extinguished  where it starts. 
>  
> Further if needed to automate things further, receiving PE could push you max number of routes it is both willing and expecting to accept on a per RT basis via simple extension to existing protocol. 
>  
> Kind regards,
> Robert.
>  
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> --
> 
> 
> Gyan Mishra
> Network Solutions Architect 
> Email gyan.s.mishra@verizon.com
> M 301 502-1347
> 
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr