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

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Apr 2021 14:16:12 +0200

Authors,

I think I have one question or suggestion.

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.

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.

Many thx,
Robert.

On Wed, Apr 14, 2021 at 11:27 PM <[email-masked]> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
>         Title           : BGP Maximum Prefix Limits Inbound
>         Authors         : Melchior Aelmans
>                           Massimiliano Stucchi
>                           Job Snijders
>         Filename        : draft-sas-idr-maxprefix-inbound-02.txt
>         Pages           : 8
>         Date            : 2021-04-14
>
> Abstract:
>    This document describes mechanisms to limit the negative impact of
>    route leaks [RFC7908] and/or resource exhaustion in BGP [RFC4271]
>    implementations.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-sas-idr-maxprefix-inbound/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-sas-idr-maxprefix-inbound-02
> https://datatracker.ietf.org/doc/html/draft-sas-idr-maxprefix-inbound-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-sas-idr-maxprefix-inbound-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Job Snijders <[email-masked]>
Date: Thu, 15 Apr 2021 16:10:20 +0200

Dear Robert,

> I think I have one question or suggestion.

Your review is appreciated!

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

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 15 Apr 2021 16:34:35 +0200

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.

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 15 Apr 2021 14:34:15 -0400

Hi Robert

I agree “soft-reconfigure inbound” should be mentioned.

With route refresh version 1 RFC 2918 the adj-rib-out or  adj-rib-in
dynamically with a soft clear in or out CLi command.

With RFC 7513 provided an enhancement to dynamically update the  adj-rib
without a CLI soft clear.

The cisco “soft-reconfigure inbound” existed for a long time prior to RFC
2918 where it creates an additional pre policy RIB, essentially a copy of
the BGP rib - pre policy.  Soft-reconfigure was the way Cisco was able to
do soft clear so you don’t have to hard clear a peer.

Once RFC 2918 came out some operators ripped out the soft-reconfigure,
however a lot of operations kept in place for troubleshooting BGP policies
issues looking at the “pre policy” RIB in and out.

For maxim prefix with  soft-reconfigure configured on a peer, I think the
pre policy rib could change or be impacted so we should definitely include
in the draft.  Since soft is pre policy and maximum prefix acts on
adj-rib-in post policy I am guessing that it may not impact the pre policy
rib.

Kind Regards

Gyan

On Thu, Apr 15, 2021 at 8:17 AM Robert Raszuk <[email-masked]> wrote:

> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: heasley <[email-masked]>
Date: Fri, 23 Apr 2021 22:03:33 +0000

> the entire idea of soft-in becomes questionable.

the rib that soft reconfig uses has to be subject to a limit; without that,
the device is not entirely protected from memory exhaustion from a massive
leak (eg: every possible /128).

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 24 Apr 2021 00:28:30 +0200

Ok good point.

But while I agree it seems that this proves that we perhaps need to have
two different inbound prefix limit parameters.

One which can protect the router from collapse - the other one which can be
custom crafted by the operator to accommodate his per peer policy.

Former would be applied pre soft-in while the latter after it.

Not trying to make it too complex - but just to reflect operationally
what's out in the wild already. If you have a single limit and apply it pre
soft-in you simply break it.

Thx,
R.

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 24 Apr 2021 00:12:59 -0400

+1 on the pre and post separate limits

If you make them both the same then it does not help in troubleshooting the
actual pre policy so has to be a much higher limit then post policy.
Definitely separate pre and post limit.

I would think the pre policy as it’s a copy of the rib pre policy and not
the ask-rib-in I would not think it would be impacted by the maximum
prefix.

I do agree that for memory issues use cases it’s a good to have a separate
pre policy maximum.

Kind Regards

Gyan.

On Fri, Apr 23, 2021 at 6:29 PM Robert Raszuk <[email-masked]> wrote:

> One which can protect the router from collapse - the other one which can
> be custom crafted by the operator to accommodate his per peer policy.
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: heasley <[email-masked]>
Date: Mon, 26 Apr 2021 21:26:10 +0000

> Definitely separate pre and post limit.

The device could *log* (with rate-limit) and discard NLRI that exceed the
limit as in case S2 case A to assist in debugging.  An implementation
might help further by keeping a discard counter.  If S2 case A or B are
used, the limit could be adjusted without disrupting the session.

Unless your peer is so old that it does not support route-refresh, is there
really a value in a limit between pre and post policy?