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

[Aijun Wang <[e-mail]>]

Hi, Igor:

 

The quota value shouldn't be changed dynamically.

 

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.  Then when the VRF limit is reached, both of them will be withdrawn via the VPN Prefixes ORF message at the same time. 

Then is it rare or impossible that your mentioned scenario will occur?

 

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] <mailto:[e-mail]> >:

Igor,

> On Aug 29, 2022, at 8:39 AM, Igor Malyushkin <[e-mail] <mailto:[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