IETF Logo Mail Archive

Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

Aijun Wang <wangaijun@tsinghua.org.cn> Tue, 30 August 2022 03:02 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 5C609C159529 for <idr@ietfa.amsl.com>; Mon, 29 Aug 2022 20:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WF01yv21_TqD for <idr@ietfa.amsl.com>; Mon, 29 Aug 2022 20:02:43 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE9CC1594A3 for <idr@ietf.org>; Mon, 29 Aug 2022 20:01:53 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown [219.142.69.75]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 4D34880007F; Tue, 30 Aug 2022 11:01:51 +0800 (CST)
From: Aijun Wang <wangaijun@tsinghua.org.cn>
To: 'Robert Raszuk' <robert@raszuk.net>, 'Igor Malyushkin' <gmalyushkin@gmail.com>
Cc: 'idr' <idr@ietf.org>, 'Sue Hares' <shares@ndzh.com>
References: <tencent_3C3279A3B4DAF8DA03F446E7AAE799D8AA09@qq.com> <CAEfhRrz5aAJmy2Ye1gqss2d72nm78n4SfeowO-FU7i4Z6Zpb+A@mail.gmail.com> <0CD78D4C-672F-41AA-8E1B-98CD8A875D21@pfrc.org> <CAEfhRrxkuYMmfcdX=M9PG2mN+D5fCBF5bVxd1bSA2O9PU5G-gA@mail.gmail.com> <000001d8bbba$ceb9e4b0$6c2dae10$@tsinghua.org.cn> <CAEfhRrwrKJ4A=QQBWRXtLKi-U0udv+zPuWoW0wqbeMQ2U-=JXA@mail.gmail.com> <CAOj+MMGLQ6enLxy36ZcFHh6qaCh7Ba1QFDa5XokccT7wvvU_fg@mail.gmail.com>
In-Reply-To: <CAOj+MMGLQ6enLxy36ZcFHh6qaCh7Ba1QFDa5XokccT7wvvU_fg@mail.gmail.com>
Date: Tue, 30 Aug 2022 11:01:50 +0800
Message-ID: <010101d8bc1c$da2391e0$8e6ab5a0$@tsinghua.org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0102_01D8BC5F.E8483170"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQK73tOJmpze6rJyNez9SrD9MPek7QK8XtYRAbOLm4wB5fkdqAD6U0deAWmRJd8B/jONs6uqqV0A
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVlDSE0aVkxOSB5KTk8fT01CQ1UTARMWGhIXJB QOD1lXWRgSC1lBWUlKQlVKT0lVTUJVTE5ZV1kWGg8SFR0UWUFZT0tIVUpKS0hKTFVKS0tZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Oio6Nzo5LT0wFUk*Lh4RPA0Q N0swCypVSlVKTU1KQ0lDTkpKQk5LVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxOWVdZCAFZQUpPSkpMNwY+
X-HM-Tid: 0a82ecb2b6dbb03akuuu4d34880007f
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/EueQLyagA8Y2ng_HuhzvHxc-5kI>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 30 Aug 2022 03:02:45 -0000

Hi, Robert:

 

Regarding to your “final question”, my answers are the followings (I think you are mentioning again the RTC based approach):

1.     The overflowed VPN routes can only be identified/triggered via the receiving/overwhelmed PE.

2.     The per RT based maximum number of routes on RR can’t represent per VRF limit on the receivers.

 

Finally, thanks for your comments and suggestions during the adoption call of this draft, the updated draft has already incorporated some of your constructive suggestions, and we are glad to hear more such kind comments later. We have discussed intensely other possible approaches, there is no easier way to achieve such goal.  

 

Best Regards

 

Aijun Wang

China Telecom

 

From: Robert Raszuk <robert@raszuk.net> 
Sent: Tuesday, August 30, 2022 12:24 AM
To: Igor Malyushkin <gmalyushkin@gmail.com>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>; idr <idr@ietf.org>; Sue Hares <shares@ndzh.com>
Subject: Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

 

 

Hi Authors of this document, 

 

I have final question to you on this proposal. 

 

Would you be willing to rewrite the draft such that the required behaviour and protection can be run on Route Reflectors and not on receiving PEs ? 

 

That way one hop ORF will easily reach the src PEs and the fire can be locally extinguished  where it starts. 

 

Further if needed to automate things further, receiving PE could push you max number of routes it is both willing and expecting to accept on a per RT basis via simple extension to existing protocol. 

 

Kind regards,

Robert.

v2.23.0 | Report a Bug | By Email