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

[Gyan Mishra <[e-mail]>]

Hi Jeffrey


On Fri, Feb 26, 2021 at 3:47 PM Jeffrey Haas <[e-mail]> 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
> 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.


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

>
>
> -- Jeff
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



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