IETF Logo Mail Archive

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:16 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 D9BC23A0975 for <idr@ietfa.amsl.com>; Wed, 10 Feb 2021 16:16:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 AgpXVaEvEVrf for <idr@ietfa.amsl.com>; Wed, 10 Feb 2021 16:16:26 -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 303783A0912 for <idr@ietf.org>; Wed, 10 Feb 2021 16:16:24 -0800 (PST)
Received: from [240.0.0.1] (unknown [106.121.164.161]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 46F451C0116; Thu, 11 Feb 2021 08:16:21 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-214FF14E-966F-45D5-B12E-19B27E004783"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Thu, 11 Feb 2021 08:16:20 +0800
Message-Id: <25A998B6-36D6-47F5-9775-B1B3DFB2C051@tsinghua.org.cn>
References: <12CC3D2A-4316-45EA-8ED8-4802F7CB56B0@cisco.com>
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <12CC3D2A-4316-45EA-8ED8-4802F7CB56B0@cisco.com>
To: "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGkMZShpKGENDS0tMVkpNSkhLS0lOQ0pPTkpVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Pk06Kjo5CD8XLS5KHTAqHy8K AwtPClFVSlVKTUpIS0tJTkNKQ0tLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKS01VSklKVUpNT1VKTUpZV1kIAVlBSktMTU83Bg++
X-HM-Tid: 0a778e72252cd993kuws46f451c0116
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jIFTFpTDESQgaaSYYTEUFa2ZlqE>
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:16:31 -0000

Hi, Acee:
Would you also to refer to my replies to Jim also based on you have same opinions with him.
Some additional replies are inline below[WAJ].


Aijun Wang
China Telecom

> On Feb 11, 2021, at 03:24, Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org> wrote:
> 
> 
> Hi Sue, IDR WG,
>  
> I agree with Jim Uttaro with respect to the use case being weak and already solved with other mechanisms.
[WAJ] Please refer my replies to Jim.
>  
> Also, there was much opposition to changing the RD semantics and using it for route filtering.
[WAJ] The RD semantic is not changed.
> See:
>  
> https://mailarchive.ietf.org/arch/browse/idr/?q=%22wang-idr-rd-orf%22
[WAJ] These are just technical discussions.
>  

> I don’t see that this has changed and,

[WAJ] The document has updated several versions upon the comments from mail list. Would you like to point out which comments is still yet addressed?

> additionally, this will add further complexity to BGP route filtering dynamics.
[WAJ]The RD-ORF mechanism is straightforward to be understood. Your complex feeling may come from it can apply several complex scenarios? I think this is its technical advantage.

> Thanks,
> Acee
>  
> 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

v2.23.0 | Report a Bug | By Email