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

Gyan Mishra <> Fri, 26 February 2021 23:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30F883A0EBF; Fri, 26 Feb 2021 15:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ncvxZAmjITGV; Fri, 26 Feb 2021 15:20:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 750E43A0E1F; Fri, 26 Feb 2021 15:20:43 -0800 (PST)
Received: by with SMTP id s16so6084797plr.9; Fri, 26 Feb 2021 15:20:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UuyW40NTX9QYuyn/ZCf7ypI5saM2VDU7v2foLfXmLk8=; b=I1vksFAHg52JRhGlY7WN0OFNe/7tZukuySS9fK1jySiRVBmKEi47y+CLjPHICeeo5I uagCH3Jld5Ph56gpIUVBvay4WbFaoaBNnhIDlkiUYLTn3qb+MOH8URiCqqm5iPKWCBQe FL2+NniIm1dvj4LOdF62iOpKYjlGqxUXwLX1TuP/MFmY/CCg6LCalob5UloZgLixJuJB mER3R2htCJOoRoIGAIsMm3fYXSBJmkw8HWKUEgFC3hSsXo4Zx/bVCn1lyX9oeSNyacEU m0oUQUxNdRjQqYfSyIgeLRxvM7eSi3s67wtmDHH02rbvRPuORnqd3xLsjbKyhHE7Ovxc oIzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UuyW40NTX9QYuyn/ZCf7ypI5saM2VDU7v2foLfXmLk8=; b=HdBqQLaFqyZlIcWaZnxgb422h5UGNTKBJ3Hjij7i10zkx9SvyVzEiSHI9/WmPqDwfC WiamG4bEuIzJ/qMaD0UCrbMGtbLuphOldu0y9tr/vUpEsO4ZhKkGbigDTFlHtAgs390H A3v4Oaq2JiAwpQ1O7MZvNMrzwdRg33qR56F5/8BnfZ/qnbuqjxj5x5WtZRxaBYJ+t9N/ 3Q+lHb9S/laHE2B04okod+Ooqov0/wnStOfuLQwA3CJrZWEwqRwgfmDjfpI7fsUBMkWO A5pixv/WvA6cGvfH/3YrsmUxsyYm2wOzssgUa+KhQtSmz0G4uaqL3+pqezMml8MhY3Fq XzdQ==
X-Gm-Message-State: AOAM530AhVB4Oaw4lNvb7aDKj5uIl5ZYBL76s0aR7N3ICBomlZGTauzu POOtP+0VQSV4Tiau6/c5L0qrrY6nX/XCCEovA6HlfCGaJNs=
X-Google-Smtp-Source: ABdhPJwyhTtsl/z34ukKiBsPreR3+hWymUN4fD5THWn1QN3awE8TrUIGGn0UWef/OLcQeu03h6kwwXDR0jH9XBXfUPo=
X-Received: by 2002:a17:90a:65c4:: with SMTP id i4mr5590524pjs.132.1614381642571; Fri, 26 Feb 2021 15:20:42 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Fri, 26 Feb 2021 18:20:22 -0500
Message-ID: <>
To: Jeffrey Haas <>
Cc: Aijun Wang <>,,
Content-Type: multipart/alternative; boundary="00000000000056626905bc458464"
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 23:20:46 -0000

Hi Jeffrey

On Fri, Feb 26, 2021 at 3:47 PM Jeffrey Haas <> wrote:

> Gyan,
> 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
> > 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.

   Gyan> Good we are on the same page.

> 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.

  Gyan> Agreed on the two issues first being how receiving PE signals

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

   Gyan> So as you stated their are two main parts to the RD-ORF solution.

Goal #1 Mitigation of all receiver PEs VPNs from overflow.  So RD-ORF
solution resolves all PEs that are signaling RD-ORF for overflow VRF.  The
receiver driven signaling completely mitigates all PEs having an overflow
issue.  So this solves #1 and #2.  We can update the draft to clarify the
receiver driven solution  signaling so the RR does not have to perform the
same procedure upstream.

Goal #2 Stop the source from sending the flood of routes.  This is more
complicated agreed and would require signaling upstream by the RR to find
the source PE based on RD+RT.  In a typical service provider core the PEs
RRC all peer to multiple RRs so the so the source PE would be one of the
PEs peering directly to the RRs so it would not be too difficult I think to
find the source PE based on RD+RT.   We will work on documenting this
scenario better.

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

   Gyan> Agreed.  The second point I think can be solved with receiver
driven signaling so the RR does not have to signal upstream.  We will work
on better documenting Goal #2 to stop the source from flooding.

> 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.

    Gyan> The major caveat with Prefix ORF is if the number of prefixes is
a high order of magnitude would make it not feasible such as a 100k route
flood.  Since the RD ORF is meant to mitigate the overflow PE the use case
would always be a very high number of prefixes that could cause resources

> -- Jeff


*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD