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> Fri, 12 February 2021 15:26 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 B56583A1742 for <idr@ietfa.amsl.com>; Fri, 12 Feb 2021 07:26:33 -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=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 E4hF6XBtAO3X for <idr@ietfa.amsl.com>; Fri, 12 Feb 2021 07:26:30 -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 5D20D3A1758 for <idr@ietf.org>; Fri, 12 Feb 2021 07:26:28 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.46.85]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id E1CEC1C01CE; Fri, 12 Feb 2021 23:26:18 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-7609875C-8ED5-4C72-9954-544CB5481B30"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 12 Feb 2021 23:26:16 +0800
Message-Id: <F3E64313-ABAD-4CB7-823E-50843990B0A7@tsinghua.org.cn>
References: <CAOj+MMEWHNcWkOjgazG21wHVrOTKSOwNM4ZKm3AAp7FRecfpYg@mail.gmail.com>
Cc: "Wanghaibo (Rainsword)" <rainsword.wang@huawei.com>, idr@ietf.org, Susan Hares <shares@ndzh.com>
In-Reply-To: <CAOj+MMEWHNcWkOjgazG21wHVrOTKSOwNM4ZKm3AAp7FRecfpYg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSkpDQkkYT0oaGEsZVkpNSkhKT0hOTEJLSE1VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hNSlVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Pww6PSo5FT8RPS09GSs9OToo TFZPCUtVSlVKTUpISk9ITkxCSENPVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU9NVUNOWVdZCAFZQUxPQ0M3Bg++
X-HM-Tid: 0a7796d9992fd993kuwse1cec1c01ce
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/pyXhNdXC8CMMqx0b4DXenHxm_Mk>
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: Fri, 12 Feb 2021 15:26:40 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 12, 2021, at 23:10, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
>> The receiver device, such as the access router, may have weak performance, while the sender device, such as the RR, may have strong performance.
>> 
> 
> Yes., That is precisely why we have  https://tools.ietf.org/html/rfc4684
> 
>> The ORF is a tool and does not exist independently. The deployment problem described here occurs only when the RD-ORF mode is used.
>> 
>> Actually, the ORF can be used together with other ORFs, such as Prefixed ORF.
>> 
>> RD-ORF provides a more efficient filtering method, making solution deployment more flexible.
>> 
>>  
>> 
>> In fact, most vendors' devices support rd-filter, but only support the configuration.
>> 
>>  
>> 
>> In addition, if the RR decides to push the RD-ORF to its route source only when PE1 and PE3 do not want that RD.
>> 
> 
> See this is one more time indication that you have serious gap in understanding L3VPNs. 
> 
> PEs which import routes do not understand sender's ORF. They take routes and based on RT make a local copy to importing VRF. 
> 
> In RFC4364 RTs are used to build arbitrary VPN topologies not RDs. 

[WAJ] Just one correction, whether RR will send the RD-ORF message out to PE1 is not depend on the reaction of PE2 and PE3, it is its own decision.
> 
> Thx
> 
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email