Re: [Idr] Adoption and IPR call for draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)

[Igor Malyushkin <[e-mail]>]

Hi Jeff,

Thanks for comments.

I`m concerned that the suggested solution covers only subset of cases. For
example, if a multihomed CE sends us lots of prefixes (that we for unknown
reason didn`t drop at ingress), one multihomed PE can distribute them
slightly faster than another one. In that case, routes from one multihoming
PE will deplet and its quota, and the VRF prefix limit. At the same time
routes from the second multihoming PE come. Let`s imagine that RR hasn`t
withdrew yet all excessive routes of the first multihoming PE, it is in the
process. Here we need to drop locally (due to the old-good prefix limit)
almost the same amount of routes (roughly) from the second leg also receive
and process withdraws from RR for the fist leg. I believe we will make
things with resources even worse. Not to mention if we will free some room
for prefixes due to ORF, we will doomed to update RIB/FIB two times in vain.

Maybe it`s a good move to count a quote independently of the VRF limit
(such mechanic isn`t described in the draft, so I`m not sure how
it actually works). In the scenario above despite we locally drop excessive
routes from the second multihoming PE due to the VRF prefix limit, we can
also reduce its quota at the same time and react much faster.

Please also see the inline.

пн, 29 авг. 2022 г. в 14:45, Jeffrey Haas <[e-mail]>:

> Igor,
>
> > On Aug 29, 2022, at 8:39 AM, Igor Malyushkin <[e-mail]>
> wrote:
> >
> >
> > In the first option, will RR withdraw all PE3`s routes until the number
> of these routes reaches to the quota of PE3, right? In such way, the
> described problem can happen only in the second scenario because there will
> be a room for the routes of PE2. If RR withdraws routes that overflowed the
> VRF prefix limit only, the described problem will actual for any case.
>
> One observation is that the local systems, when examining their quotas,
> can use the fact that it knows that a given RD is intended to be mitigated
> by the ORF or not.
>
> Exactly how the system needs to behave in the implementation would
> partially depend on the reason for mitigation.  For memory exhaustion, it
> may need to be more aggressive about discarding routes.  For CPU overload,
> lesser mitigations may be sufficient.
>
[IM] Actually overloading of a VRF prefix limit (which starts sending of an
ORF message) does not mean that there are any problems with the memory or
CPU. It is just a threshold, a device can even locally drop all excessive
routes without any starvation of its resources. This threshold (VRF limit)
is an only good and reliable trigger for us. We also can`t know beforehand
what problem is actual in the case of routes overloading, it may be either
a memory problem, or a CPU one, or even both. So I can`t see a way to
configure "the aggressiveness mode" for the proposed solution either. Or I
didn`t get your point.

>
> I think the critical implementation detail is that once this ORF is
> triggered, it should require operator intervention to clear to avoid
> thrashing routes.
>
[IM] Operator`s intervention should be triggered earlier, when the quota
has passed. But I agree that number of excessive routes can be so much so
it will run through the quota and the VRF limit almost simultaneously.

>
> -- Jeff
>
>