From nobody Wed May 12 20:15:10 2021 Return-Path: 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 A5F373A21AA for ; Wed, 12 May 2021 20:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EROMOA-UWED1 for ; Wed, 12 May 2021 20:15:03 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 5F6CF3A21A7 for ; Wed, 12 May 2021 20:15:03 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id t193so7459376pgb.4 for ; Wed, 12 May 2021 20:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Civk6brv5WyxuDbZZKdJzRf4ExdlQZBH7h948B2Sxac=; b=Ts8DaPw78UO2NqrIc7BBMlQbjstMuYoAqTkbfxy5hxjbSE9OqFWsMvKZf0twcxdkIy AfOShkfG87b4m6PRFjvfXvhoLtfHYJgfVvXuNWbNs3IA97ldr1DqDZp93kToy5RWqLdk x71nEhyc5EOHonANeVrnVFPmgtRMSIq1iKkxrAfootq9rrnD3o1qNjLcfN6Yo8X1A7qT +e2QojIcK3Nigl2UCGjrBFhDTFqJ/FeW90k2cUablUGE2iVAzRxp5Mh52ReWjOG59iTT uXNj6GcQ64LJCyqkYOc3qin6QYOM8SrzWuyfVLjKLMJGTDeVHc5Q75ZDg5Uc/KCMfmX8 1LXA== 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=Civk6brv5WyxuDbZZKdJzRf4ExdlQZBH7h948B2Sxac=; b=Xz0pxXb9KbdNuq28FBE9O4E8UWbIPTXv0/WVgTp2+23I2YFjtqTpBn/ydrEvxKwzzv Lq6L0ZeFlCiad08FNg8KoryXcYvS3k5+47+5ZZPDwVJClzjZ/r7ESsW7qSS3YdDHn/vA ymnptDLjd1o3AvZVV9hY3ShKA36Wb1PtZG0EC6FK0hinPrM+tGIUe8I8n6238i/TF0pW QuInCVTt0yr6q6aJUyH/Z6t1x3Rq01CKqWW8gkhkNOb98toJREO7+cqXy932gRfIpXy9 8Ckw2t7WzMWBBD6cjaV8HjPt3XYk4wxPlSAMhlEfddCsWEySEI45P8od8ZvbcMEcdHOh h4jg== X-Gm-Message-State: AOAM532HgVwAf4GfYC2LBeffbh8VBHI3j0YiUkRNutAfxkWMGszAfPAu oErW0CGKwvR7C4/nxzTVwKDLsGP5bIW+b7YMv3U= X-Google-Smtp-Source: ABdhPJy0siDebvU4JHr7T1i7+pHHjgstmI1Qkz6fG8bR1ax9IpSAUgoTLRondRVQ26TDqW5xsADkoVJe1ZfKQX7Rwys= X-Received: by 2002:a17:90a:4608:: with SMTP id w8mr42636785pjg.132.1620875702313; Wed, 12 May 2021 20:15:02 -0700 (PDT) MIME-Version: 1.0 References: <161843563034.11054.13811966622190622752@ietfa.amsl.com> In-Reply-To: From: Gyan Mishra Date: Wed, 12 May 2021 23:14:51 -0400 Message-ID: To: Robert Raszuk Cc: "Jakob Heitz (jheitz)" , Melchior Aelmans , Melchior Aelmans , "idr@ietf. org" Content-Type: multipart/alternative; boundary="00000000000076272605c22d880d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 03:15:09 -0000 --00000000000076272605c22d880d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think from a NOC perspective you want flexibility and so I agree on having two separate maximum prefix for pre and post policy and for both maximum prefix exceeded being able to drop the peer. As I stated the impact is more with post policy with next hop tracker table walk and control and data plane, however I do agree that in a case of flood of routes that the pre policy can definitely have significant impact as well. +1 more for implementation not for draft Thanks Gyan On Wed, May 12, 2021 at 5:33 PM Robert Raszuk wrote: > Jakob, > > Spot on. > > That is why I mentioned that the very same max-prefix when applied > pre-policy vs post-policy can have a different value. > > But I guess this is implementation thing not so much an IETF draft one. > > Thx, > R. > > On Wed, May 12, 2021 at 11:26 PM Jakob Heitz (jheitz) > wrote: > >> The reason to terminate the session is illustrated in: >> >> >> https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-bgp-m= aximum-prefix-limits-00 >> >> >> >> Suppose you have a customer whose prefix advertisements vary somewhat, >> >> so you give him a decent margin. Suppose you set max-prefix to 1000 >> >> and on a fateful day he advertises 200 prefixes. >> >> You have some good inbound filters for him, but not perfect, again, >> >> because the prefixes he advertises vary somewhat. >> >> Now, on this day, he leaks the internet to you and you manage to filter >> most of it out, >> >> but several routes sneak past your filter and leak. >> >> Those that sneak past your filter are not enough to trip your max-prefix >> of 1000. >> >> If you have a pre-policy max-prefix of, say, 10000, that will easily >> catch the leak >> >> and you could terminate the session to stop the leak. >> >> >> >> Regards, >> >> Jakob. >> >> >> >> *From:* Idr *On Behalf Of * Gyan Mishra >> *Sent:* Wednesday, May 12, 2021 12:20 AM >> *To:* Melchior Aelmans >> *Cc:* idr@ietf. org ; Melchior Aelmans < >> maelmans@juniper.net>; Robert Raszuk >> *Subject:* Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt >> >> >> >> >> >> 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 sto= red >> 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. I= n >> general the trigger event peer being clamped down would happen on the po= st >> policy adj-rib-in as that value would always be lower then the pre polic= y >> adj-rib-in. In that respect thought I can=E2=80=99t see a scenario wher= e the pre >> policy maximum prefix would take down the peer over the post policy maxi= mum >> prefix. That being said I am not sure we really need a pre policy maxim= um >> prefix. >> >> >> >> I understand the reason behind it to save on memory copy of tbt >> ash-rib-in but I don=E2=80=99t think the action that the peer must be ta= ken 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 pl= ane >> 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 cas= e >> if it was a Must to clamp down the peer due to pre policy being exceeded >> where post policy was not exceeded I don=E2=80=99t think that=E2=80=99s= a good idea as is >> impacting. I think for pre policy maybe only a warning should be allowe= d >> but not clamping down the peer. >> >> >> >> Gyan >> >> >> >> >> >> On Tue, May 11, 2021 at 12:13 PM Melchior Aelmans >> wrote: >> >> 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 b= e >> 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 an= d >> 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 o= r >> 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. Otherw= ise >> 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 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 t= o >> > change it however put some light that if >> > configured by the operator some of the benefits of inbound prefix limi= t >> > 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 >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> >> -- >> >> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email gyan.s.mishra@verizon.com * >> >> *M 301 502-1347* >> >> >> > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000076272605c22d880d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I think from a NOC perspective you want fl= exibility and so I agree on having two separate maximum prefix for pre and = post policy and for both maximum prefix exceeded being able to drop the pee= r. =C2=A0 As I stated the impact is more with post policy with next hop tra= cker table walk and control and data plane, =C2=A0however I do agree that i= n a case of flood of routes that the pre policy can definitely have signifi= cant impact as well. =C2=A0

+1 more for implementation not for draft=C2=A0
<= br>
Thanks=C2=A0

Gyan

On Wed, May 12, 2021 at 5:33 PM Robert Raszuk <= robert@raszuk.net> wrote:
Jakob,

Spot on.=C2=A0

That is why I mentioned that the= very same max-prefix when applied pre-policy vs post-policy can have a dif= ferent value.=C2=A0

But I guess this is implementa= tion thing not so much an IETF draft one.=C2=A0

Th= x,
R.

On Wed, May 12, 2021 at 11:26 PM Jakob Heitz (jheitz) = <jheitz@cisco.com<= /a>> wrote:

T= he reason to terminate the session is illustrated in:<= /p>

<= a href=3D"https://datatracker.ietf.org/meeting/104/materials/slides-104-gro= w-bgp-maximum-prefix-limits-00" target=3D"_blank">https://datatracker.ietf.= org/meeting/104/materials/slides-104-grow-bgp-maximum-prefix-limits-00<= u>

<= u>=C2=A0

S= uppose you have a customer whose prefix advertisements vary somewhat,

s= o you give him a decent margin. Suppose you set max-prefix to 1000

a= nd on a fateful day he advertises 200 prefixes.

Y= ou have some good inbound filters for him, but not perfect, again,

b= ecause the prefixes he advertises vary somewhat.

N= ow, on this day, he leaks the internet to you and you manage to filter most= of it out,

b= ut several routes sneak past your filter and leak.

T= hose that sneak past your filter are not enough to trip your max-prefix of = 1000.

I= f you have a pre-policy max-prefix of, say, 10000, that will easily catch t= he leak

a= nd you could terminate the session to stop the leak.

<= u>=C2=A0

R= egards,

J= akob.

<= u>=C2=A0

From: Idr <idr-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Wednesday, May 12, 2021 12:20 AM
To: Melchior Aelmans <melchior@aelmans.eu>
Cc: idr@ietf. org <idr@ietf.org>; Melchior Aelmans <maelmans@juniper.net>; Robert Raszuk &= lt;robert@raszuk.net= >
Subject: Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.tx= t

=C2=A0

=C2=A0

After thinking about it I agree that that the prefix= pre and post can definitely be different.=C2=A0 The pre policy is a copy o= f the adj-rib-in stored separately in memory so the limit values can defini= tely 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 va= lue to trigger the neighbor being clamped down. In general the trigger even= t peer being clamped down would happen on the post policy adj-rib-in as that value would always be lower t= hen the pre policy adj-rib-in.=C2=A0 In that respect thought I can=E2=80=99= t see a scenario where the pre policy maximum prefix would take down the pe= er over the post policy maximum prefix.=C2=A0 That being said I am not sure we really need a pre policy maximum prefix. =C2= =A0=C2=A0

=C2=A0

I understand the reason behind it to save on memory = copy of tbt ash-rib-in but I don=E2=80=99t think the action that the peer m= ust be taken down if pre policy maximum is exceeded if the post policy is n= ot exceeded.=C2=A0 The post policy the control plane rib is programmed into hardware for forwarding so there is more impa= ct to resources both control and data plane for post policy as opposed to p= re policy is control plane copy and also is not advertised to other peers a= s well as are pre policy prefixes.=C2=A0 Much less impact if pre policy is exceeded.=C2=A0

=C2=A0

I think the case where a peer advertisement went fro= m 100k to 2M and the pre policy was set to=C2=A0

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 po= licy being exceeded where post policy was not exceeded =C2=A0I don=E2=80=99= t think that=E2=80=99s a good idea as is impacting.=C2=A0 I think for pre policy maybe only a warning should be allowed but not clampi= ng down the peer.

=C2=A0

Gyan=C2=A0

=C2=A0

=C2=A0

On Tue, May 11, 2021 at 12:13 PM Melchior Aelmans &l= t;melchior@aelmans= .eu> wrote:

Ack Robert, thanks for confirming.

=C2=A0

Cheers,

Melchior

=C2=A0

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

Hi Melchior,=C2=A0

=C2=A0

After rethinking this I think the current text in th= e=C2=A0draft is ok.=C2=A0

=C2=A0

It is after all optional cfg and=C2=A0if vendor supp= orts both pre and post policy=C2=A0max-prefix limit inbound the configured = numbers may not need to be identical.

=C2=A0

Thx,

R.

=C2=A0

=C2=A0

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

Hi Robert, all,

=C2=A0

First of all thanks for your feedback!=

=C2=A0

The part we are confused about is that soft-reconfig= uration inbound is a Cisco command to enable=C2=A0adj-RIB-In which then sto= res all the received routes. On Juniper and OpenBGPd (and possibly other im= plementations as well) adj-RIB-In is enabled by default and protected by a maximum-prefix limit inbound.<= /p>

Could you please elaborate on what you are exactly t= rying to describe and as Job suggested make suggestions for text adjustment= s?

=C2=A0

Thanks!
Melchior

=C2=A0

On Thu, Apr 15, 2021 at 4:36 PM Robert Raszuk <robert@raszuk.net&= gt; wrote:

Hi Job,

=C2=A0

The distinction between Per and Post policy is clear= .=C2=A0

=C2=A0

Inbound Prefix Limit=C2=A0may (depending on implemen= tation) apply to either or both of those processing stages.=C2=A0=

=C2=A0

The observation I am trying to make is that IMHO sof= t in is not really a Pre Policy in a sense=C2=A0that you must not apply Pre= fix Limit to it. Otherwise the entire idea of soft-in becomes questionable.= =C2=A0

=C2=A0

To me perhaps the proper way to visualize it is actu= ally to divide Pre Policy into two blocks - ALL Prefixes and Pre-Policy Pre= fix-Limited. All Prefixes block would occur only when soft in is enabled. O= therwise some may expect or request to apply Inbound Prefix Limit before routes are stored when soft reconfigu= ration inbound=C2=A0is enabled.=C2=A0

=C2=A0

Or perhaps you actually want to do that sort of brea= king that knob ?=C2=A0

=C2=A0

Many thx,

R.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Thu, Apr 15, 2021 at 4:10 PM Job Snijders <job@fastly.com> wro= te:

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<= br> > maintains the above behaviour at least some of the justifications for<= br> > the document is gone.

Interesting, the draft's objective is to clarify that inbound limits ca= n
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 t= o
> change it however put some light that if
> configured by the operator some of the benefits of inbound prefix limi= t
> will not be fully effective.

What you call 'soft-reconfiguration inbound' ends up storing into w= hat
the draft refers to as 'Pre Policy'. (At least... that is the inten= tion,
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
htt= ps://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
Idr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/idr

--

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com<= /u>

M 301 502-1347

=C2=A0

--
--00000000000076272605c22d880d--