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

Hi Melchior,

After rethinking this I think the current text in the draft is ok.

It is after all optional cfg and if vendor supports both pre and post
policy max-prefix limit inbound the configured numbers may not need to be
identical.

Thx,
R.

On Tue, May 11, 2021 at 3:22 PM Melchior Aelmans <melchior@aelmans.eu>
wrote:

> Hi Robert, all,
>
> First of all thanks for your feedback!
>
> The part we are confused about is that soft-reconfiguration inbound is a
> Cisco command to enable adj-RIB-In which then stores all the received
> routes. On Juniper and OpenBGPd (and possibly other implementations as
> well) adj-RIB-In is enabled by default and protected by a maximum-prefix
> limit inbound.
> Could you please elaborate on what you are exactly trying to describe and
> as Job suggested make suggestions for text adjustments?
>
> Thanks!
> Melchior
>
> On Thu, Apr 15, 2021 at 4:36 PM Robert Raszuk <robert@raszuk.net> wrote:
>
>> Hi Job,
>>
>> The distinction between Per and Post policy is clear.
>>
>> Inbound Prefix Limit may (depending on implementation) apply to either or
>> both of those processing stages.
>>
>> 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.
>>
>> To me perhaps the proper way to visualize it is actually to divide Pre
>> Policy into two blocks - ALL Prefixes and Pre-Policy Prefix-Limited. All
>> Prefixes block would occur only when soft in is enabled. Otherwise some may
>> expect or request to apply Inbound Prefix Limit before routes are stored
>> when soft reconfiguration inbound is enabled.
>>
>> Or perhaps you actually want to do that sort of breaking that knob ?
>>
>> Many thx,
>> R.
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 15, 2021 at 4:10 PM Job Snijders <job@fastly.com> wrote:
>>
>>> Dear Robert,
>>>
>>> On Thu, Apr 15, 2021 at 02:16:12PM +0200, Robert Raszuk wrote:
>>> > I think I have one question or suggestion.
>>>
>>> Your review is appreciated!
>>>
>>> > As you all know some implementations allow you to explicitly force BGP
>>> > speaker to keep (pre-policy) all routes/paths received.
>>> >
>>> > Example:
>>> >
>>> > neighbor 192.168.1.1 soft-reconfiguration inbound
>>> >
>>> > The draft does not seem to comment on this case yet if implementation
>>> > maintains the above behaviour at least some of the justifications for
>>> > the document is gone.
>>>
>>> Interesting, the draft's objective is to clarify that inbound limits can
>>> be applied at multiple stages of the pipeline (pre and post policy), not
>>> all Network Operating Systems appear to offer this (operationally
>>> speaking much needed) granularity, and through this draft we hope to
>>> clarify to implementers that it is something worth considering to add.
>>>
>>> > I think that draft should at least mention such behaviour, not force to
>>> > change it however put some light that if
>>> > configured by the operator some of the benefits of inbound prefix limit
>>> > will not be fully effective.
>>>
>>> What you call 'soft-reconfiguration inbound' ends up storing into what
>>> the draft refers to as 'Pre Policy'. (At least... that is the intention,
>>> it is possible the text is readable to us but not easy to understand for
>>> others)
>>>
>>> Do you have specific text in mind to add to the draft to clarify this?
>>>
>>> Kind regards,
>>>
>>> Job
>>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>