Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 11 February 2021 00: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 637103A0C88 for <idr@ietfa.amsl.com>; Wed, 10 Feb 2021 16:38:54 -0800 (PST)
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 iEjwBAUX5Dg7 for <idr@ietfa.amsl.com>; Wed, 10 Feb 2021 16:38:51 -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 D2FC03A0C87 for <idr@ietf.org>; Wed, 10 Feb 2021 16:38:50 -0800 (PST)
Received: from [240.0.0.1] (unknown [106.121.164.161]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 42CB31C00AC; Thu, 11 Feb 2021 08:38:46 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-7A558A14-B7F3-4759-9635-BCA5F162AB20"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Thu, 11 Feb 2021 08:38:45 +0800
Message-Id: <3D4E7BD5-B093-481C-A49F-CE60A3DA601C@tsinghua.org.cn>
References: <DM6PR13MB2330AA84B5872CCB40FA3A70858D9@DM6PR13MB2330.namprd13.prod.outlook.com>
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <DM6PR13MB2330AA84B5872CCB40FA3A70858D9@DM6PR13MB2330.namprd13.prod.outlook.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGEMfGEJPQh8dSh5KVkpNSkhLS0hCSU1OSk1VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MAw6Nzo6Lj8LTC4iQjAQHw0* IyFPCgJVSlVKTUpIS0tIQklNQktCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpNT1VKTUpZV1kIAVlBSU9KS083Bg++
X-HM-Tid: 0a778e86ab03d993kuws42cb31c00ac
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LSlJ7Xsopm3bPjs_1nwE85GOhnA>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
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: Thu, 11 Feb 2021 00:38:54 -0000

Hi, Linda:
Thanks for your support!
The answer to your questions are inline below.[WAJ]

Aijun Wang
China Telecom

> On Feb 11, 2021, at 01:23, Linda Dunbar <linda.dunbar@futurewei.com> wrote:
> 
> 
> I support the WG adoption.
> Answers to the questions posted by the Chair:
>  
> 1)      Will this new ORF filter reduce routing information at key points?
> Yes, the proposed approach prevents more routes sent to a PE whose VRF overflows.
>  
> 2)      Should the WG consider this draft given it has an IPR claim or Would the IDR WG prefer another approach?
> Yes,  because the IPR has  FRAND royalty-bearing licenses
>  
> 3) Is this draft ready to be adopted and refined as WG draft?
> Yes.
>  
> Some questions to the Author:
> 1)      On Page 3 (right below Figure 1), you have:
> “When the VRF of VPN1 in PE1 overflows, due to PE1 and other PEs are
> not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the
> problem on PE2 cannot be known”
>  
> Do you mean that “the problem on PE1 cannot be known” to others?  
[WAJ] You are right. I think this is a typo. Will update in next version.
>  
> 2)      2 Does PE1 have preconfigured “BGP Maximum prefixes” expected from others?
[WAJ] “BGP Maximum prefixes can only be configured between BGP peers. In the RR topology(Figure 1) scenario, such mechanism can only be applied between PE1 and RR, which can’t prevent the overflow of specified VPN routes.
> If more than expected prefixes are received, is it because other PEs’ fault in sending trashing prefixes? Or is it because the PE1 configuration error?
[WAJ] We are considering mainly the other PE’s fault in sending trash prefixing.

> 3)      RD-ORF ROUTE-REFRESH message is propagated to all other PEs, Do all the PEs receiving the message stop sending “that VPN route” (as described in 5.1.3?
[WAJ] No, such message is only transferred only to the overflowing PE, that is, the PE that emit the most part of VPN routes.
>  
>  
> Linda Dunbar
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Wanghaibo (Rainsword)
> Sent: Wednesday, February 10, 2021 2:28 AM
> To: Susan Hares <shares@ndzh.com>; idr@ietf.org
> Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> Hi Sue and All,
>  
> I support the adoption as a co-author.
>  
> 1)      Will this new ORF filter reduce routing information at key points?
> Yes
> 2)      Should the WG consider this draft given it has an IPR claim or
> Would the IDR WG prefer another approach?
> Yes,
> 3) Is this draft ready to be adopted and refined as WG draft?
> Yes, the extension is useful for this scenario, and we may explore more scenes with it.
>  
> Best Regards,
> Haibo
>  
>  
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
> Sent: Thursday, February 4, 2021 11:38 PM
> To: idr@ietf.org
> Subject: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
>  
> This begins a 2 week WG adoption call for draft-wang-idr-rd-orf-05.txt (from 2/4/2021 to 2/18/2021)
>  
> This draft defines a new Outbound Route Filter (ORF) type, called the
> Route Distinguisher ORF (RD-ORF).  RD-ORF is applicable when the
> routers do not exchange VPN routing information directly (e.g.
> routers in single-domain connect via Route Reflector, or routers in
> Option B/Option AB/Option C cross-domain scenario).
>  
> Please be aware that this draft has one IPR statement attached.
> https://datatracker.ietf.org/ipr/4579/..
>  
> Please consider the following questions in your review and comments:
>  
> 1) Will this new ORF filter reduce routing information at key points?
> 2) Should the WG consider this draft given it has an IPR claim or
>     Would the IDR WG prefer another approach?
> 3) Is this draft ready to be adopted and refined as WG draft?
>  
> Cheerily, Susan Hares
>  
>  
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr