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

Aijun Wang <wangaijun@tsinghua.org.cn> Thu, 16 July 2020 02:40 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 C78A33A0A63 for <idr@ietfa.amsl.com>; Wed, 15 Jul 2020 19:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 IHToD1s403c8 for <idr@ietfa.amsl.com>; Wed, 15 Jul 2020 19:40:33 -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 8A7113A0A65 for <idr@ietf.org>; Wed, 15 Jul 2020 19:40:32 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m127101.qiye.163.com (Hmail) with ESMTPA id 6961945E8E; Thu, 16 Jul 2020 10:40:28 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Robert Raszuk'" <robert@raszuk.net>, <wangw36@chinatelecom.cn>, "'Aijun Wang'" <wangaj3@chinatelecom.cn>
Cc: "'idr@ietf. org'" <idr@ietf.org>
References: <CAOj+MMH_CefbH639OVs==ts4C_7rf4W1d+pUN+Wb+im5+gNfFg@mail.gmail.com>
In-Reply-To: <CAOj+MMH_CefbH639OVs==ts4C_7rf4W1d+pUN+Wb+im5+gNfFg@mail.gmail.com>
Date: Thu, 16 Jul 2020 10:40:28 +0800
Message-ID: <003c01d65b1a$777b60a0$667221e0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D65B5D.85A22310"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQNnRYCq6s5hfjVD8h6OyPDXWyFosqXnmOPg
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZSUMYS0pCTR1PQklLVkpOQk9DTUxJSUNNQ0tVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0hKTFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6NFE6ODo4IzguUTQ8DC0SNEhW IRgaFAtVSlVKTkJPQ01MSUlCSkxCVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpNTE9MNwY+
X-HM-Tid: 0a73557e9fa59865kuuu6961945e8e
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/X2r_ZgfZUpDjr5GsrDW6RWbr1-M>
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: Thu, 16 Jul 2020 02:40:36 -0000

Hi, Robert:

 

Thanks for your reviews and comments.

As you said, RD is to make the VPN prefix unique within the VPN’s domain. It can also be used to identify the VPN customer.

The usage of RT, just as you said, is to control what routes are distributed where, that is to say, to control the customer’s VPN topology. RT can’t be used to identify one VPN customer.

 

The scenarios/problems described in this draft(https://tools.ietf.org/html/draft-wang-idr-rd-orf-00) are not for the VPN topology control, but for the VPN prefix limit management, which is signed along with the agreement with the VPN customer.

This is the reason that we select the RD-based ORF control mechanism.

 

More detail reply are inline below. Wish to get more your comments/suggestions on them.

 

Thanks in advance.

 

Best Regards

 

Aijun Wang

China Telecom 

 

From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, July 16, 2020 2:26 AM
To: wangw36@chinatelecom.cn; Aijun Wang <wangaj3@chinatelecom.cn>
Cc: idr@ietf. org <idr@ietf.org>
Subject: [Idr] https://tools.ietf.org/html/draft-wang-idr-rd-orf-00

 

Dear Aijun & Wei,

 

I have read your draft as per subject. 

 

I think there is a serious misunderstanding on what RD's role is in RFC4364. 

 

RDs MUST never be used to signal anything which would in any way influence what routes are distributed where. Their sole role is to make the VPN prefix unique across given VPN's domain. 

【WAJ】RD can be used to identify one VPN customer

 

It is RTs which are used to import routes to VRFs on PEs. What you are trying to do is exactly why we have defined some time back RTC (RFC4684). Applications from section 5.1 and 5.2 can be happily addressed with use of RTC. 

【WAJ】RT is used to control VPN topology, same as the mechanism of RTC(4684). But the application described in section 5.1 and 5.2 of this draft is not for VPN topology control, but for VPN route-limit management, which is based on customer/RD.

 

Informationally let me also point out that RFC7543 has defined extensions to ORF to signal RTs for reducing size VPN RIBs in specific Hub & Spoke topologies. 

【WAJ】RFC7543 is to pull the prefix that cover one specific host address, to get the more optimal route information from the Hub, not the same scenarios as described in the current draft.

 

Last your proposal calls for treating ORF as a transitive message without any loop protection. That is not a good idea. 

【WAJ】ORF messages are exchanged within only the directed BGP sessions. Such Messages will be regenerated when it is needed to send to another BGP peer.  Would you like to describe more for the loop scenarios? 

 

I recommend to protect your PEs from being overwhelmed by VPN routes by prefix limit instead. 

【WAJ】Prefix Limit mechanism can be used for Option –A, but not for Option B/C, as that described in the draft.

 

Kind regards,

R.

 

PS. Did we have any discussion in IDR or BESS on this proposal ?