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 12:04 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 008903A11EB for <idr@ietfa.amsl.com>; Mon, 15 Feb 2021 04:04:16 -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 56Z1nD9gzOGl for <idr@ietfa.amsl.com>; Mon, 15 Feb 2021 04:04:13 -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 D2B4A3A11E6 for <idr@ietf.org>; Mon, 15 Feb 2021 04:04:12 -0800 (PST)
Received: from [240.0.0.1] (unknown [111.194.51.239]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id 3BBEC1C00B9; Mon, 15 Feb 2021 20:04:09 +0800 (CST)
Content-Type: multipart/alternative; boundary=Apple-Mail-5092FF82-63E2-4143-A084-1165E88E32AE
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Feb 2021 20:04:08 +0800
Message-Id: <1862A0E5-D14C-4D60-B55B-F5B9377E6838@tsinghua.org.cn>
References: <B2B7D017-79C6-49CF-8AA0-8330E4CE91F4@tsinghua.org.cn>
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org
In-Reply-To: <B2B7D017-79C6-49CF-8AA0-8330E4CE91F4@tsinghua.org.cn>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (18D52)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VLWVdZKFlBSkxLS0o3V1ktWUFJV1 kPCRoVCBIfWUFZGklOSR0fSksaGk9KVkpNSkhIQktNT0JISEtVEwETFhoSFyQUDg9ZV1kWGg8SFR 0UWUFZT0tIVUpKS0JITVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6PxA6Txw6DT8XISwyCjIuSkwt I0wKCTJVSlVKTUpISEJLTU9CTEpLVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlKSkpVSkJPVU5KVUlIQllXWQgBWUFKSEpCTjcG
X-HM-Tid: 0a77a593979ed993kuws3bbec1c00b9
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/n8C01a-NV3qrwD8LJ33F4ij8GsU>
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 12:04:16 -0000

And Gyan from Verizon has also explained in previous mail the necessary for such mechanism.

Aijun Wang
China Telecom

> On Feb 15, 2021, at 20:02, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> 
> Hi, Robert:
> 
> Aijun Wang
> China Telecom
> 
>>> On Feb 15, 2021, at 18:53, Robert Raszuk <robert@raszuk.net> wrote:
>>> 
>> 
>> Aijun,
>> 
>>>> > 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). 
>>>> 
>>>> I am not sure what is yr definition of "solve" - but sending RD3_RT3 tuple will be no worse then sending RD3 alone. And in many situations as I illustrated before (hub and spoke case) will actually prevent unreachability across VRFs. 
>>> 
>>> [WAJ] Yes, adding RT information within the current RD-ORF encoding can certainly increase the accuracy of the offending VPN routes. 
>> 
>> Agreed. 
>> 
>>  
>>> But in situations described in Figure 3, RD3/RT3 is same for VRF1/2/3. If only one of VRF reach the VPN prefixes limit, it should not influence otherVRF. In such situation, the RD-ORF message should still not be triggered by the PE device, even we use the RD/RT tuple.
>> 
>> Well this is first time I hear you saying that - but sure triggering sending RD-RT filter would be a local decision anyway. 
>> 
>> 
>>>> > don’t know why it selected new SAFI NLRI approach.
>>>> 
>>>> Because ORF is NOT transitive. ORF has no concept of loop prevention.
>>> 
>>> [WAJ] ORF is route policy to BGP neighbors. It should not be transitive. It does not announce the reachable information, nor the nexthop change, why to consider loop prevention?
>> 
>> 
>> I am talking about control plane loop not data plane loop. 
>>  
>>>> It *only* works p2p. Propagation of received ORF entries is something we should explicitly forbid in ORF spec.
>>> [WAJ] Yes. The p2p mode is fine for ORF message. No need to propagation. Every node should determine based on its own condition.
>> 
>> See you are again trying to propagate ORF. 
>> 
>> This spec should make it as a MUST that such filter should be triggered only upon import "overflow". That way RRs will not be by the spec able to send such filters if you insist to put in ORF msg. See RRs do not know what routes PEs are importing in terms of RD. So it would be bad to assume so here as well. And for RT they know only if RTC is in use across 100% of PE-RR sessions. 
> 
> [WAJ] RR can deduce RT information from the RD-ORF message of its clients. There maybe other ways to get, we will try to find later if the RT information is associated. 
>> 
>> 
>>>> Maybe time for a -bis. 
>>>> And the objective of RTC is to build a controlled distribution graph of information across ASNs. That is why this draft https://tools.ietf.org/html/draft-chen-bgp-ext-community-orf-02 did not progress. 
>>> [WAJ] RTC is used to announce “what I want”, it has no mechanism to express “What I don’t want”, which the ORF mechanism jump in.
>>> 
>>> Then, considering your suggestions, I think adding RT information to current RD-ORF encoding is the appropriate approach, instead of changing the concept/procedures of RTC.
>> 
>> No one is suggesting touching RTC SAFI 132. We are talking about new SAFI which can just provide finer filtering in addition to RTC. It can be used alone or with RTC - no issue either way. 
>> 
>> But again this is all applicable only when there is a serious problem. So far I have not seen much support in terms of operators outside of China asking for this filtering regardless if this is in ORF or in new SAFI. 
> 
> [WAJ] As I mentioned before, we are aiming at the inter-AS VPN services deployment which only be emerged when one operator has wide-spreads inter-AS network topology.
>> 
>> Thx,
>> R.
>>