Re: [Idr] Fwd: I-D Action: draft-sas-idr-maxprefix-outbound-00.txt

[Ben Maddison <[e-mail]>]

Hi all,

On 10/06, Warren Kumari wrote:
> <no hats>
> On Wed, Sep 30, 2020 at 10:53 AM Gyan Mishra <[e-mail]> wrote:
> >
> > Hi Authors
> >
> >
> > Would it be possible to modify the action so that we have the option to not disconnect the peer and allow the peer to remain UP state but clip the routes above the upper limit and provide this option for both inbound and outbound directions.
> 
> Errrr... how sure are you that this is the behavior that you *want*?
> If you have tripped the max-prefixes limit it's almost always:
> 1: things have been slowly growing over time, you've tripped your
> warning limit. The right thing to do here is carefully look at the
> prefixes, make sure they are what you expect, and bump it up by a bit.
> 2: you've just borked your filters and are now trying to leak full
> tables to your peers. The right thing to do here is tear the session
> down and go do penance...
> 
> I strongly suggest taking this question to GROW / NOGs before adding a
> "send as many as you can and then start filtering" option; tripping
> the hard limit should be the same as a circuit breaker, not a
> resistor.

I'm with Warren on this.
If the log that the warning level generates goes unnoticed, then it's highly
likely that whatever byzantine forwarding issue the "clipping" creates
will do so too, and possibly persist for a long time.

I wouldn't want to be the on-call engineer in the middle of the night
that has to make the logical leap from a ticket that says "we're seeing
a weird-looking traceroute ..." to "we have half-tripped someone else's
max-prefix limit".

Additionally there is also no guarantee that in the event of a leak the
"leaked" prefixes are the ones that are "clipped". It's just as likely
that you end up with the worst case scenario of causing an outage for
the legit prefixes *and* allowing the leak to persist!

Cheers,

Ben