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

Gyan Mishra <> Wed, 12 May 2021 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 170313A3800 for <>; Wed, 12 May 2021 00:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id emTsVQTd0IWz for <>; Wed, 12 May 2021 00:19:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D363C3A3802 for <>; Wed, 12 May 2021 00:19:46 -0700 (PDT)
Received: by with SMTP id g24so13041455pji.4 for <>; Wed, 12 May 2021 00:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CQtqAA+CCeMi3EmMsN0zf0JYGC6Hkc8dszt8MvwFGzs=; b=JgMxtiNTvccwJfA72qAAIrDp5pXBp1f8yWvH9NuYyJ5tfMozk6XoyYhMaXJFD4cnki nQ+obxNZGMu0oOIbU+ikaYi79gmK75eud+sDxX3bZjIywVWKg1Kr6MOhU6ZzIf3QfsuZ Lnve734D4FGZoE0Mqba/fiosGqEAh28TVJIJdS1EulxwuxKEz4g3BV4mqCnLAIoIzX9L pTj6KrVF/BgJp11tN9nxSvYVyHkEekj0O3E+LULho9KLRHH6kNudRpmRLbv3a7usqoRm RQOcWpc7h405eO+spL1My+91r5tQ6zK7pqCczEybjp0uefE/pxy9qYIwvjIbIpeDnoRv GjLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CQtqAA+CCeMi3EmMsN0zf0JYGC6Hkc8dszt8MvwFGzs=; b=bfSUgJFJlu8fim+Dx4jjwgPaFHhSSOmHWt0PIURx2fc+1HAZEVAnflU6lR2GdbejBY jj7PKDRCfzSaFbvbaXNnfmz2EvH9to1nOHkwqOxoCDTxU+wlpFRIeriqFfRv4XH1jsuc FK7chMY+hRueEvymgdwL5owXq30AslEf7VlPGTTrRFcOO4STwN34np8Pi3vyHK2FVq1n 2z1wamfVpqVwPJsB1AyHvLI3F9Ipzs+8pVMlXFLxaWxwjZNtoKP8mv3AwVVR8a2W54/F qkMljUjE4QlmyMDH3g4kP15iYe2Xc42MxckdMciwVCn089q6aEVZhq6vDcby8d3BPmrm wquw==
X-Gm-Message-State: AOAM530ombv471JWelvXKNid9dikfY6/3vNGqZb7DsC8DlA/gnBIqiEF kIFD87NZOklxGBQ+ngGKfZ3el2CObnNA0wCFaLE=
X-Google-Smtp-Source: ABdhPJwjJ2EIYj0qvuR19D9PP60fHxHZuh0nk/VvPgxpjtNsysQlIqebzKuvUnLlwd6aLSQn1W8ZbDwAud940dbMc2c=
X-Received: by 2002:a17:90a:4608:: with SMTP id w8mr37649273pjg.132.1620803985336; Wed, 12 May 2021 00:19:45 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <YHhJTB51/joiz9Pg@snel> <> <> <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Wed, 12 May 2021 03:19:34 -0400
Message-ID: <>
To: Melchior Aelmans <>
Cc: Melchior Aelmans <>, Robert Raszuk <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000cbed9a05c21cd5d4"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 May 2021 07:19:52 -0000

After thinking about it I agree that that the prefix pre and post can
definitely be different.  The pre policy is a copy of the adj-rib-in stored
separately in memory so the limit values can definitely be different. In
such case as the pre policy is pre inbound filter so it can have a very
high water mark for maximum prefix, and the post policy would have the
maximum prefix exact value to trigger the neighbor being clamped down. In
general the trigger event peer being clamped down would happen on the post
policy adj-rib-in as that value would always be lower then the pre policy
adj-rib-in.  In that respect thought I can’t see a scenario where the pre
policy maximum prefix would take down the peer over the post policy maximum
prefix.  That being said I am not sure we really need a pre policy maximum

I understand the reason behind it to save on memory copy of tbt ash-rib-in
but I don’t think the action that the peer must be taken down if pre policy
maximum is exceeded if the post policy is not exceeded.  The post policy
the control plane rib is programmed into hardware for forwarding so there
is more impact to resources both control and data plane for post policy as
opposed to pre policy is control plane copy and also is not advertised to
other peers as well as are pre policy prefixes.  Much less impact if pre
policy is exceeded.

I think the case where a peer advertisement went from 100k to 2M and the
pre policy was set to
1M and the post policy was set to 100k and 100k was received in this case
if it was a Must to clamp down the peer due to pre policy being exceeded
where post policy was not exceeded  I don’t think that’s a good idea as is
impacting.  I think for pre policy maybe only a warning should be allowed
but not clamping down the peer.


On Tue, May 11, 2021 at 12:13 PM Melchior Aelmans <>

> Ack Robert, thanks for confirming.
> Cheers,
> Melchior
> On Tue, May 11, 2021 at 3:51 PM Robert Raszuk <> 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 <>
>> 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 <> 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 <> 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 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 mailing list


*Gyan Mishra*

*Network Solutions A**rchitect *

*Email <>*

*M 301 502-1347*