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

Jeffrey Haas <> Fri, 26 February 2021 20:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B4E613A0657; Fri, 26 Feb 2021 12:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lN76wwvqzlYk; Fri, 26 Feb 2021 12:47:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E7A523A0652; Fri, 26 Feb 2021 12:47:47 -0800 (PST)
Received: by (Postfix, from userid 1001) id BFEBD1E447; Fri, 26 Feb 2021 16:08:23 -0500 (EST)
Date: Fri, 26 Feb 2021 16:08:23 -0500
From: Jeffrey Haas <>
To: Gyan Mishra <>
Cc: Aijun Wang <>,,
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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 20:47:50 -0000


On Thu, Feb 25, 2021 at 10:52:25PM -0500, Gyan Mishra wrote:
> 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.

I agree that RT-Constrain does not solve all of the problems, nor is my
intent to suggest that it does.  It does suggest that a hard problem has
some possible answers.

There are two issues here:
1. How does a receiving PE signal that it wants to STOP receiving some
routes?  RD-ORF is an example of that.  

2. How does something that receives the signal from the first item decide
whether it can perform the same procedure "upstream"?  

I believe that the second point will be very hard to solve and urge the
authors to spend time documenting the scenarios.

Alternatively, if the problem to be solved is restricted to the first case,
I think you have a constrained problem that can be readily solved either
through Prefix ORF or even RD-ORF as special case of Prefix-ORF.

-- Jeff