Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 21 July 2020 14:32 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 07D673A0912 for <idr@ietfa.amsl.com>; Tue, 21 Jul 2020 07:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Level:
X-Spam-Status: No, score=-1.817 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zltlfRzhuGG8 for <idr@ietfa.amsl.com>; Tue, 21 Jul 2020 07:32:02 -0700 (PDT)
Received: from mail-m127101.qiye.163.com (mail-m127101.qiye.163.com [115.236.127.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198833A08FE for <idr@ietf.org>; Tue, 21 Jul 2020 07:32:00 -0700 (PDT)
Received: from [240.0.0.1] (unknown [106.121.178.155]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 7C2BA4BB2C; Tue, 21 Jul 2020 22:31:55 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-CA9E6DA5-A44A-4D71-9570-628C416329E4"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Tue, 21 Jul 2020 22:31:52 +0800
Message-Id: <5D32E53E-AD24-4651-95FC-64BDE9FD992C@tsinghua.org.cn>
References: <29371221afa24063bc397b063c950507@att.com>
Cc: Robert Raszuk <robert@raszuk.net>, "idr@ietf. org" <idr@ietf.org>
In-Reply-To: <29371221afa24063bc397b063c950507@att.com>
To: "UTTARO, JAMES" <ju1738@att.com>
X-Mailer: iPhone Mail (17F80)
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGB1CGUJCSUJOTE5PVkpOQk5IT0pCSk5NTk9VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS09ISFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MSo6DCo5Ej8uSBZOHgkIIw43 AwIKC0hVSlVKTkJOSE9KQkpNS09CVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpMQ1VKTk5ZV1kIAVlBSklOQ0s3Bg++
X-HM-Tid: 0a7371c9c5769865kuuu7c2ba4bb2c
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/XFOApMsikQ1dmn1FoVKYvO0bBMg>
Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
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, 21 Jul 2020 14:32:05 -0000

Managing the VPN route table overflow or managing RTs for VPN? We are discussing the former.

Aijun Wang
China Telecom

> On Jul 21, 2020, at 22:04, UTTARO, JAMES <ju1738@att.com> wrote:
> 
> 
> We have been managing it for 20+ yrs. It is fairly straightforward..
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Aijun Wang
> Sent: Tuesday, July 21, 2020 5:28 AM
> To: 'Robert Raszuk' <robert@raszuk.net>
> Cc: 'idr@ietf. org' <idr@ietf.org>
> Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>  
> Hi, Robert:
>  
> It’s possible, but is not easy management as using RD-ORF. 
> We should also consider that RTs for one VPN can be changed due to inter-VRF communication.
>  
>  
> Best Regards
>  
> Aijun Wang
> China Telecom
>  
> From: Robert Raszuk [mailto:robert@raszuk.net] 
> Sent: Tuesday, July 21, 2020 5:17 PM
> To: Aijun Wang <wangaijun@tsinghua.org.cn>
> Cc: Jakob Heitz (jheitz) <jheitz@cisco.com>; Jeff Tantsura <jefftant.ietf@gmail.com>; idr@ietf. org <idr@ietf.org>
> Subject: Re: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00
>  
>  
> RR can have its own policy to propagate such messages to upstream peer, depends on its capabilities.
>  
> That now sounds like a very SDN like controller - not a BGP RR. 
>  
> I have one final question: 
>  
> Do you agree that you can accomplish exactly what you need by proper RT assignment and use of RTC ? 
>  
> Thx,
> R.