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

[Gyan Mishra <[e-mail]>]

Hi Igor

In the dual homes CE scenario the paths advertised from CE1 would have path
id 1 and the prefixes from CE2 would have a different path id homed to the
same PE, and if add paths is enabled on all PEs for diverse pathing the
redundant path may also have a different path id as the withdrawal is done
based on the path id.  So I don’t see the withdrawal causing any kind of
race conditions.

Kind Regards

Gyan
On Mon, Aug 29, 2022 at 12:09 PM Igor Malyushkin <[e-mail]>
wrote:

> 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
>>
>> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*