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

Ack Robert, thanks for confirming.

Cheers,
Melchior

On Tue, May 11, 2021 at 3:51 PM Robert Raszuk <robert@raszuk.net> wrote:

> 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
>>>
>>