Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 26 February 2021 23:38 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 7A6013A13F9; Fri, 26 Feb 2021 15:38:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 Saa3fbNN2bwz; Fri, 26 Feb 2021 15:38:42 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D113A13F8; Fri, 26 Feb 2021 15:38:41 -0800 (PST)
Received: from [240.0.0.1] (unknown [106.121.135.123]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 85C881C00E3; Sat, 27 Feb 2021 07:38:38 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-F2EBC329-6CD2-4388-99C7-42F68C731EF1
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Message-Id: <B2A16443-7F32-4D67-977C-F4E4584DB27C@tsinghua.org.cn>
Date: Sat, 27 Feb 2021 07:38:37 +0800
Cc: Gyan Mishra <hayabusagsm@gmail.com>, draft-wang-idr-rd-orf@ietf.org, idr@ietf.org, Aijun Wang <wangaj3@chinatelecom.cn>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZT09OGkwfHhgaTR9NVkpNSk9IQ0lMSkNNQ09VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0NISFVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MD46Mhw6Fj8QSBIfIQItFTof HwgaCz5VSlVKTUpPSENJTEpCS09JVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpITlVKSUhZV1kIAVlBT0hKTzcG
X-HM-Tid: 0a77e0b55e57d993kuws85c881c00e3
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/J50Q8s_nNIaUIEEBYHS8H9sbNEc>
Subject: Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)
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, 26 Feb 2021 23:38:46 -0000

Hi, Robert:

RD only filter can fit some situations, but as also your considerations, there are situations that RD only information is ambiguous. We have considered such scenarios and are considering to include RT information within the current RD-ORF semantic.
Then, even for Issue 1 as Jeff summarized, the Prefix-ORF is not suitable.


Aijun Wang
China Telecom

> On Feb 27, 2021, at 07:27, Robert Raszuk <robert@raszuk.net> wrote:
> 
>>     Gyan> The major caveat with Prefix ORF is if the number of prefixes is a high order of magnitude would make it not feasible such as a 100k route flood.  Since the RD ORF is meant to mitigate the overflow PE the use case would always be a very high number of prefixes that could cause resources exhaustion.
> 
> RD is nothing else then /64 prefix. 
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr