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 Aijun,

We can see the solution to the problem differently, but I think any
solution must not create additional problems.

I`m not sure that with possible race conditions this solution doesn`t pose
new problems with the processing of updates.


пн, 29 авг. 2022 г. в 17:20, Aijun Wang <[e-mail]>:

> Hi, Igor:
>
>
>
> The quota value shouldn't be changed dynamically.
>
[IM] Ok, it was bad wording. I mean to count received routes over a quota
even if the VRF prefix limit is reached.

>
>
> In your mentioned scenario(CE is dual homed to two PEs), normally the
> routes from the first PE and second PE will pass their quotas at the same
> time first.
>
[IM] What do you mean by "normally"? We *expect *that they will be received
by a destination PE almost at the same time, but it is not guaranteed.

> Then when the VRF limit is reached, both of them will be withdrawn via the
> VPN Prefixes ORF message at the same time.
>
[IM] This statement is based on a previous invalid assumption.

>
>
> Then is it rare or impossible that your mentioned scenario will occur?
>
[IM] I don`t think that multihoming of CE is rare, also I don`t think that
multihoming PEs will send updates at the same time at the same pace (lots
of reasons for that).

Aijun Wang
>
> China Telecom
>
>
>
>
>
> *发件人:* [e-mail] [mailto:[e-mail]] *代表 *Igor
> Malyushkin
> *发送时间:* 2022年8月29日 21:27
> *收件人:* Jeffrey Haas <[e-mail]>
> *抄送:* idr <[e-mail]>; Sue Hares <[e-mail]>
> *主题:* Re: [Idr] Adoption and IPR call for
> draft-wang-idr-vpn-prefix-orf-03.txt (8/16 to 8/30)
>
>
>
> 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
>
>