Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Aijun Wang <> Mon, 15 February 2021 12:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 922F63A11E6 for <>; Mon, 15 Feb 2021 04:01:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.005
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CFPdJvd0oCH4 for <>; Mon, 15 Feb 2021 04:01:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 829553A11E5 for <>; Mon, 15 Feb 2021 04:01:44 -0800 (PST)
Received: from [] (unknown []) by (Hmail) with ESMTPA id 432901C009A; Mon, 15 Feb 2021 20:01:41 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-B1F63507-EF1D-4FD2-A363-AC2E86D28AC7"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Feb 2021 20:01:40 +0800
Message-Id: <>
References: <>
Cc: Susan Hares <>,
In-Reply-To: <>
To: Robert Raszuk <>
X-Mailer: iPhone Mail (18D52)
X-HM-Tid: 0a77a591559dd993kuws432901c009a
Archived-At: <>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Feb 2021 12:01:52 -0000

Hi, Robert:

Aijun Wang
China Telecom

> On Feb 15, 2021, at 18:53, Robert Raszuk <> wrote:
> Aijun,
>>> > But it seems adding RT information can’t still solve the situation described in 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 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.