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> Mon, 15 February 2021 02:09 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 3A97E3A103D for <idr@ietfa.amsl.com>; Sun, 14 Feb 2021 18:09:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.005
X-Spam-Level:
X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 YGza5TQR0YW4 for <idr@ietfa.amsl.com>; Sun, 14 Feb 2021 18:09:41 -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 739633A103A for <idr@ietf.org>; Sun, 14 Feb 2021 18:09:40 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.51.239]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 8D3861C0188; Mon, 15 Feb 2021 10:09:36 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-43D219BA-C2B9-4419-A0F9-48197F918B1E
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Message-Id: <676733B1-2A7D-4AA3-B2F4-28F0FDB6F8F6@tsinghua.org.cn>
Date: Mon, 15 Feb 2021 10:09:35 +0800
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGhpNSx1JSR5PSBhNVkpNSkhITk9CTE1MSk1VEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Ohw6PBw6HD8RDywYCjA1DTIY OBwKCjpVSlVKTUpISE5PQkxMS01CVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU5KVUlIQllXWQgBWUFKS0tJSDcG
X-HM-Tid: 0a77a3734543d993kuws8d3861c0188
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6yCYpjxf9ccJDEDgFEi2PiRjRBk>
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: Mon, 15 Feb 2021 02:09:45 -0000

Hi, Robert:

Thanks for your suggestions!
But it seems adding RT information can’t still solve the situation described in https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf-05#section-5.1.1(Figure 3). The overwhelmed PE need still the local determined behavior(which we will add more clear description for this part later) to trigger the RD-ORF.
And, defining one new SAFI to enhance the RTC mechanism, won’t it confuse the deployment of both? Actually, I think the RTC solution(RFC4684) should be implemented also on ORF mechanism, don’t know why it selected new SAFI NLRI approach.
Regarding to your worry for the regeneration of RD-ORF on RR/ASBR, I think we can consider it in another viewpoint: Treating RR/ASBR as the leader/proxy of its clients/neighbors, it should know the responsibilities/risks when it trigger the RD-ORF message to upstream neighbors (we need also describe more later on the determined behaviors of these devices later).

And, using ORF mechanism can achieve the granular control effects( it is hop-by-hop action), contrary to the new SAFI solution, which will be advertised immediately to network wide?
Anyway, we will try to incorporate your finer control suggestions in later design, for example, adding RT information to solve the situation that you mentioned before?
Looking forward to more suggestions/consideration on the solution.

Aijun Wang
China Telecom

> On Feb 15, 2021, at 07:38, Robert Raszuk <robert@raszuk.net> wrote:
> 
> Hello Aijun,
> 
> I have been re-thinking over a weekend this entire discussion. 
> 
> I think I have a suggestion for you which addresses my concerns and I believe also addresses yours (and your co-authors) requirements. 
> 
> As I said number of times I still suggest we do not send RD to filter. Instead we send tuple RD+RTs and only filter VPN routes on logical AND of all (all as there can be more then one RT importing given route therefore we need to include intersection of local import RTs and RTs carried with "offending" routes). 
> 
> And to make this easily transitive I recommend we just define a new SAFI for it. We can call it RTC+ or Enhanced RTC as examples. Syntax would be identical to RTC, semantics opposite. Today RTC defines RTs which PEs need. Here we would signal description of subset of those which are "excessive" to be dropped on the peer. 
> 
> Sending it with ORF say RDRT-ORD (while works p2p)  I do not buy this implicit regeneration hack say at RRs, RRs doing option C or ASBRs performing option B. So sending it in new SAFI IMHO would be much cleaner. 
> 
> Just a thought how we could perhaps move forward here. 
> 
> Kind regards,
> Robert
> 
> 
> On Sat, Feb 13, 2021 at 3:32 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
>> Hi, Susan:
>> 
>> Thanks for your suggestions. More responses from the operators are welcome!
>> We think this mechanism can let the network cope with dynamically the extraordinary scenarios for VPN routes advertisement, especially the inter-AS Option B/C scenarios. 
>> This can certainly encourage the widespread deployment of inter-AS option B/C solution(especially for EVPN/VXLAN, EVPN/SRv6) increase the VPN services coverage and revenue of the operators.
>> 
>> There may be some details procedures and device behaviors need to be clarified further, but this is not unsolvable, considering there are so many experts within IDR WG.
>> 
>> Thanks Robert, Jakob, Jim and Acee for the technical challenges to let us/IDRer understand the solution more clearly.
>> 
>> Aijun Wang
>> China Telecom