Subject: Re: [GROW] Comments on draft-sa-grow-maxprefix

From: Melchior Aelmans <[email-masked]>
Date: Wed, 6 Mar 2019 14:57:29 +0100

Hi Tim,

Thanks for your feedback! Apologies for getting back so late to your
comments!
Some questions/responses in line below.

On Fri, Dec 28, 2018 at 4:53 PM Tim <[email-masked]> wrote:

> 1. Related with Considerations for soft thresholds
>
> Actually the behavior after reaching threshold include:
>
> Soft limit:
>
> 1) Alert only: Only alert triggered, neighbour is not impacted
>

Agreed and widely implemented for inbound advertisements. It is potentially
useful as well outbound.

> 2) Alert + Stop receiving route: Alert triggered, no extra route accepted.
>

I think if you apply this both inbound and outbound the result is useless
as it is arbitrary based on the order you advertise or receive routes in.
Do you agree?

Hard limit:
>
> Tear down the session, either idle forever or reconnect after a period
> of time.
>

How about if you allow the session to come back up and advertisements are
blocked until you are sure the queue doesn't contain too many routes?

2. Generally to protect network from impact of route leaking, based on
> my experience only relying on prefix limit mechanism is not enough.
> Reason include:
>
> 1) Prefix limit is usually neighbor basis, while route leaking could
> happen on multiple neighbors together.
>

Agreed. Max prefix out should be made available on global, group and
neighbour level.
I would propose to cover this in the "Implementation Guidance" section.

> 2) Consideration also need include devices on POP that receive all
> internet routes from internet gateway via RR. Such devices could hold
> multiple services not only just BGP.
>
> In such case, either a BGP process based or global based memory&CPU
> protection mechanism is needed.
>

What do you propose? I don't see how prefix limits could play a role here?

3. There is one more case need to consider is that a device could be
> able to receive BGP prefix and add in RIB even, but when it send the
> route to other neighbors, especially when number of neighbors is large.
>
> update package group could help in such scenario, but still all msgs
> need to be sent to TCP socket that will consume extra memory after all
> route already received,
>
> There are some implementations already so far (at least IOS XR supports
> bgp write-limit) to limit the msgs speed sent to update group to remit
> impact of this.
>
> Overall, it depends on intention of this draft, it is to define pre &
> post policy on prefix limit or provide a practical solution for route
> leaking.
>
> If the intention is the latter one, I would say we could be more work to
> do.  If is the previous one, I would say no objection on current scope.
>

I would suggest to keep the scope limited for now and agree there's more
work to be done in this space...for another draft :)

> 4. It may be useful to describe advantages of type B
>
> In case of a neighbor send illegal routes (e.g. rfc 6598), such routes
> are not accepted (filtered by policy) and not calculated, it won't lead
> to reset of a BGP neighbor mistakenly.
>

Agreed that it is a good example.

5. In the last, related with Implementation status:
>
> I can provide implementation status on Huawei devices:
>

Great, thanks! Will accumulate that into the draft.

Finally thanks for the draft again.

You are welcome. Feel free to add additional comments.

Thanks!
Melchior

---

From: Yu Tianpeng <[email-masked]>
Date: Mon, 11 Mar 2019 11:58:57 +0000

Hi Melchior,
Thanks a lot for the feedback.
Response inline below.

Regards,
Tim

On Wed, 6 Mar 2019, 13:57 Melchior Aelmans, <[email-masked]> wrote:

> Agreed and widely implemented for inbound advertisements. It is
> potentially useful as well outbound.
>
>
[Tim]: the device must clear all buffers before trying to reconnect.

> What do you propose? I don't see how prefix limits could play a role here?
[Tim] No. It rely on a global based memory protection of the os system.
Let's keep it out of this document so far.

> work to be done in this space...for another draft :)
[Tim] Agree.