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

Job Snijders <> Thu, 15 April 2021 14:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08D623A214A for <>; Thu, 15 Apr 2021 07:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZPPQl9StV-cn for <>; Thu, 15 Apr 2021 07:10:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D47F3A215F for <>; Thu, 15 Apr 2021 07:10:25 -0700 (PDT)
Received: by with SMTP id j12so3215414edy.3 for <>; Thu, 15 Apr 2021 07:10:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5L0L1LuJwC9OVi/KtJuP+VvlTp/JXKjKtd1TIAFUTf0=; b=E5qbKUm6AOitzg8ug8S5cjo319kTz1gdKN+G+bAc2JpMkfY0A0tz2++Czx0iiUp/Ad eGtmK/FN7d7x3oxqGraWg58CgI3fGO7hhTeby5aJccNk1A4N2n8e89y3ntbF8LQujVVE +SihUXb+ZKeeRIRRWQ6CJBhwCCZkhho3vGtdk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5L0L1LuJwC9OVi/KtJuP+VvlTp/JXKjKtd1TIAFUTf0=; b=iDTEIHiOgR1JiKLapKFC4XmcyDYsXoiuDlVl2nFJJE1kB6PYrOPc92xkRWtFCwgzyh SyzY5W3n9mUPlz6ps6R7yisPTpVNONv9qyT+ezlCDi4yTGZ0IDJVUe2sGY5GO1pE3VNk lWZxFqkA1JgxV+rUZ2kbysOJEv6Urfo//3qLkc9Z/xs2Kegrma/HkC/sDnIauDGYt8xJ 31vrOShYh2YQtJ0IqSwG5xcacfn10KGBrOVGwIumr9J9wdWEx5UD7glu3W2/vS/H9gq0 6D6/e7xBlE+/aUY7O7NQLF0j9nLT8M/sRztcoNZYYd4xf3iSEGiQJC6GZvCD0dcydfRL mFaQ==
X-Gm-Message-State: AOAM532eBuTER/Zw8aHzx87jGWPxWFKhorf/WxAJYH25WtZOv0Qd1LJ0 bYcVYQhZGx72ibAFpzXP55Oi3g==
X-Google-Smtp-Source: ABdhPJzgGd6/EajuPWNFOpLBQXBJUaGrDNAmN9oFRkjRKdggnS3Kk6WxgaOg8hWudtYs+bCkYuNDCw==
X-Received: by 2002:a05:6402:3596:: with SMTP id y22mr4453477edc.207.1618495822178; Thu, 15 Apr 2021 07:10:22 -0700 (PDT)
Received: from snel ( []) by with ESMTPSA id z6sm1979564ejp.86.2021. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Apr 2021 07:10:21 -0700 (PDT)
Date: Thu, 15 Apr 2021 16:10:20 +0200
From: Job Snijders <>
To: Robert Raszuk <>
Cc:,, "idr@ietf. org" <>
Message-ID: <YHhJTB51/joiz9Pg@snel>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
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: Thu, 15 Apr 2021 14:10:30 -0000

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

Do you have specific text in mind to add to the draft to clarify this?

Kind regards,