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

Robert Raszuk <robert@raszuk.net> Thu, 15 April 2021 14:34 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F333A225C for <idr@ietfa.amsl.com>; Thu, 15 Apr 2021 07:34:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA9l6Wp3Aisc for <idr@ietfa.amsl.com>; Thu, 15 Apr 2021 07:34:54 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC603A2254 for <idr@ietf.org>; Thu, 15 Apr 2021 07:34:53 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id o16so27360441ljp.3 for <idr@ietf.org>; Thu, 15 Apr 2021 07:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uxCYgbWoWlNRZF2zwEAdhRAM22s+7UR7zS87y98s434=; b=aNal2cVUln4uCf1tdLYHTMsbIUU/68J3C0qw+84n5mT56fsY0scxhMiTYF9XXcSaWe 9/2scwGh3NUfHAUsJDLGcroZHQJNFEyTzCRdLPl/EPcJG1qBsLfS5larqBYyKcNnc+9r AI1PAFc0JhsoOVFJB8UvJy2N3cZxGzY4KcQ3d4wKDmIi/5KzO//Pidh9Y3Kb+pZpyomd xfKPezZDk60i6LgwpjWUc1FetX6tyy0EfpVFKz9XQpPlGtzbuTvd5fOz7psRjBImNQqE YYjegIQ7MlbmdbzYrgArfO6vKv1z22rIXbamX9yAG46DvqdlgfymjG22NsgdgJR6F/+K SJqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uxCYgbWoWlNRZF2zwEAdhRAM22s+7UR7zS87y98s434=; b=HFDusUWNXbvrcDpomOuYsm6swPShPfzoRHLJdskI1rtxHuZ7Nxe8W2a9N9FFT592GM Zgopqs4BYiha7RlrVFZBHkIOVOYW5Nk5+526Pfbcj4D01Q4Nt/CR4cSK3WuA4+WRiYWe sYvSIiZm1Bsoi0bKrE7QaqqzGRPgvEXSIo/6Wc91wZFYIIn0KuDW1T/n4UVkjhPo5ydk VNBoDCQwfs1tu9xK5wKMSePJHmJYkY8S+MOkhcl63iNHmSgQO7UIRmOiuOPonxVuDgjE ezQt2DHEJ55U+HSjZ80CDu/MIifQnbuXUeFm+eR1iDFlkJ/AOZQMiRoJh1A91v+UCDnu XpqQ==
X-Gm-Message-State: AOAM532tpCz7xzy69P8wJSgm23ivbByU1obcqk5xiFL7dvlWtjNmzKCa gZiOpjcRWcliscgEJPpiSVNJP2wS14Pzld39PBEMqpgwtSU=
X-Google-Smtp-Source: ABdhPJwWPgGtRaF8QJfNsNrveubGpbbiNN0DK0lba6YeIK+7UMR+FuODmbkd0tmYuLH+WTHx4rF+o35GnuQKnjX+3E8=
X-Received: by 2002:a05:651c:3c5:: with SMTP id f5mr2075034ljp.54.1618497286439; Thu, 15 Apr 2021 07:34:46 -0700 (PDT)
MIME-Version: 1.0
References: <161843563034.11054.13811966622190622752@ietfa.amsl.com> <CAOj+MMH=cCgtn7cL=HvOjQOMH1B9tmjOYOT04jXE9oky4SuevQ@mail.gmail.com> <YHhJTB51/joiz9Pg@snel>
In-Reply-To: <YHhJTB51/joiz9Pg@snel>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 15 Apr 2021 16:34:35 +0200
Message-ID: <CAOj+MMEFOGm=hCQcZNAUoN8vsPeVT3gqnjsQihUMJo4AOObZfw@mail.gmail.com>
To: Job Snijders <job@fastly.com>
Cc: maelmans@juniper.net, max@stucchi.ch, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4166305c003c3c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/icqdnfhJ_Jq--NLMG4CGdf0xZg8>
Subject: Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Apr 2021 14:35:04 -0000

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
>