Re: [Idr] draft-wang-idr-vpn-prefix-orf-00.txt- Adoption call (2/4/2022 to 2/18/2022)

[Aijun Wang <[e-mail]>]

Hi, Jeffrey:
I think there are some misunderstanding about the VPN Prefix ORF mechanism.

As stated in https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-prefix-orf-01#section-4.1.1, once the threshold is reached(for example, 80% of the max routes in one VRF), the PE will begin to monitor the upcoming VPN routes. 
And, as you assumed, if in such time, the 850k routes are coming to this PE from the RR.
The PE will trigger and send out the VPN Prefixes ORF mechanism upon it receives the 20% of the VRF routes limits. This value will be far less than your 850k.(We call this time is T1)
When the RR receives such messages, it will act immediately the filter.(We call this time is T2). The most part of the 850k routes will be filtered at the RR, thus release the PE to parse all of them.
The only passed routes are carried within the BGP Updates from T1 to T2. These are also the routes that should be withdrawn from the PE. Its value will also be far less than the 850k.
It won’t also require the local discard of 850k routes. 
Isn’t this the value of ORF mechanism?

We have stated several times that local discard doesn’t release the PE from processing the overwhelmed routes.


Aijun Wang
China Telecom

> 在 2022年2月22日，20:44，Jeffrey Haas <[e-mail]> 写道：
> 
> Gyan,
> 
> On Mon, Feb 21, 2022 at 10:42:23PM -0500, Gyan Mishra wrote:
>>> And that's throwing out the routes locally anyway.
>>> 
>> 
>> Gyan> The RD ORF is a method of locally mitigating no different then
>> applying a local filter to block the source RD route leak, but I agree you
>> avoid the 850k withdrawal message processing, however the local filter
>> requires manual intervention.  I think it would be difficult to  automate
>> a local protection mechanism.
> 
> Are you making the assumption that your trigger mechanism couldn't simply
> cause your implementation to discard routes?
> 
> If so... that's weird.
> 
> A prefix-limit can certainly just start discarding routes that are out of
> bounds.  Consider Juniper's "drop-excess":
> 
> https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/ref/statement/prefix-limit-edit-protocols-bgp.html
> 
> I typically do not recommend customers rely on this form of the
> configuration.  It leads to less than deterministic behaviors and has the
> issues of forwarding problems when more specific prefixes are being discarded
> in the presence of less specific ones.
> 
> But much like the problem statement in your I-D, sometimes it's necessary.
> 
> -- Jeff
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr