Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)

Aijun Wang <> Fri, 26 February 2021 11:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 303CD3A1370; Fri, 26 Feb 2021 03:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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 266Po0PpjsRa; Fri, 26 Feb 2021 03:26:54 -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 B3F323A136F; Fri, 26 Feb 2021 03:26:53 -0800 (PST)
Received: from [] (unknown []) by (Hmail) with ESMTPA id EE5F01C00D0; Fri, 26 Feb 2021 19:26:49 +0800 (CST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Aijun Wang <>
Mime-Version: 1.0 (1.0)
Date: Fri, 26 Feb 2021 19:26:48 +0800
Message-Id: <>
References: <>
Cc: Gyan Mishra <>, Aijun Wang <>,,
In-Reply-To: <>
To: Robert Raszuk <>
X-Mailer: iPhone Mail (18D52)
X-HM-Tid: 0a77de17607ad993kuwsee5f01c00d0
Archived-At: <>
Subject: Re: [Idr] draft-wang-idr-vpn-routes-control-analysis (was Re: rd-orf problem clarification at the local level)
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: Fri, 26 Feb 2021 11:26:56 -0000

Hi, Robert:

Your proposal just let RTC act as the behavior of RD-ORF. 
I think no one will agree with you.

I think what Jeff’s proposal is to utilize the information from RTC to let the RR decide when to send out the RD-ORF message on behalf of its peers, not to change the behavior of RTC.

Aijun Wang
China Telecom

> On Feb 26, 2021, at 18:48, Robert Raszuk <> wrote:
> Gyan,
> What you said is pretty obvious I think to everyone here.
> But I think the point of bringing RTC into this picture was a bit
> different.
> Just imagine RTC is running between PE and RR and signals interest in set
> of RTs to the RR. Let's say those RTs are RT100, RT200, RT300, RT400, RT500
> Further imagine one VRF importing RT200 overflows on said PE with incoming
> (pre-import routes of RD_FOO and RT100, RT200 and RT 300).
> So what if now PE via RTC will simply readvertise interest to get RT200
> with new BGP attribute say called BLOCK_RD and lists in such attribute body
> Route Distinguisher of RD_FOO ?

[WAJ] The action on RR then will be advertised VPN routes that with RT200, but the RD part is not RD_FOO?

> The overall mission accomplished. No need for any new ORF type. It can be
> even transitive if we apply a little hack and adjust the way RR will select
> the best path for RTC (meaning include this attribute in advertisements
> only if all peers sending RT200 attached it with such RD_FOO).

[WAJ] Normally RTC message will be flooded within the network immediately . Your proposal here just let it wait responses from all its peers. If so, why using BGP UPDATE message?

> To me this is very simply RTC extension and it seems solves this entire
> "problem".
> And no - by proposing the above I am not changing my mind that it is simply
> wrong network operation to even allow such problem to happen in the first
> place.
> Best,
> R.
>> On Fri, Feb 26, 2021 at 4:52 AM Gyan Mishra <> wrote:
>> Hi Jeff
>> Keep in mind that RTC is an optimization that does not apply to every
>> scenario especially in cases where all PEs have all the same VPNs defined
>> with explicit RT import.  The special cases were RTC does apply is for
>> incongruent VRFs in cases of a sparse RT distribution graph where PEs don’t
>> all import the same RTs.  By default all PE have RT filtering enabled by
>> default meaning if their is not an explicit VRF definition to match and
>> import the RT, the RT is dropped.  With RTC the distribution graph of what
>> RTs are advertised RR-PE is now optimized with RT membership, and now  only
>> RTs explicitly imported by the PEs are now advertised by the RR to PE for
>> processing.  In the case of RD-ORF, it provides a layer of needed
>> granularity as the RD PE originator of the flood is a subset of all the VPN
>> prefixes represented by the RT permitted by RTC to be advertised to the
>> PE.  The RD-ORF now dynamically blocks the offending PE prefixes that would
>> otherwise have been advertised by RTC RR to PE and accepted by the PE for
>> processing and added to the VRF RIB being overloaded.
>> Kind Regards
>> Gyan
>> On Thu, Feb 25, 2021 at 6:21 PM Aijun Wang <>
>> wrote:
>>> Hi, Jeff:
>>> Thanks for your suggestions!
>>> I think combine RTC and RD-ORF information can accomplish the fine
>>> control for the upstream propagation of unwanted VPN routes.
>>> We will also try to find other ways to achieve the same effect.
>>> Aijun Wang
>>> China Telecom
>>>> On Feb 25, 2021, at 22:01, Jeffrey Haas <> wrote:
>>>> Aijun,
>>>> On Thu, Feb 25, 2021 at 12:07:49PM +0800, Aijun Wang wrote:
>>>>>> In the prior discussions, it was clear that remediation was trying to
>>> be
>>>>>> done on a per-RD basis.  The text in this draft seems to be a larger
>>> scope
>>>>>> than that; perhaps per VPN (and thus route-target?).  Is that your
>>>>>> intention?
>>>>> [WAJ] Yes. We are considering to add RT information to the current
>>> RD-ORF
>>>>> semantic, to identify/control the "excessive routes" in more granular