Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt

+1 on the pre and post separate limits

If you make them both the same then it does not help in troubleshooting the
actual pre policy so has to be a much higher limit then post policy.
Definitely separate pre and post limit.

I would think the pre policy as it’s a copy of the rib pre policy and not
the ask-rib-in I would not think it would be impacted by the maximum
prefix.

I do agree that for memory issues use cases it’s a good to have a separate
pre policy maximum.

Kind Regards

Gyan.

On Fri, Apr 23, 2021 at 6:29 PM Robert Raszuk <robert@raszuk.net> wrote:

> Ok good point.
>
> But while I agree it seems that this proves that we perhaps need to have
> two different inbound prefix limit parameters.
>
> One which can protect the router from collapse - the other one which can
> be custom crafted by the operator to accommodate his per peer policy.
>
> Former would be applied pre soft-in while the latter after it.
>
> Not trying to make it too complex - but just to reflect operationally
> what's out in the wild already. If you have a single limit and apply it pre
> soft-in you simply break it.
>
> Thx,
> R.
>
>
> On Sat, Apr 24, 2021 at 12:03 AM heasley <heas@shrubbery.net> wrote:
>
>> Thu, Apr 15, 2021 at 04:34:35PM +0200, Robert Raszuk:
>> > The observation I am trying to make is that IMHO soft in is not really a
>> > Pre Policy in a sense that you must not apply Prefix Limit to it.
>> Otherwise
>> > the entire idea of soft-in becomes questionable.
>>
>> the rib that soft reconfig uses has to be subject to a limit; without
>> that,
>> the device is not entirely protected from memory exhaustion from a massive
>> leak (eg: every possible /128).
>>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*