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

[Yu Tianpeng <[e-mail]>]

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

Regards,
Tim

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

> 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 <[e-mail]> 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?
>
[Tim]: the device must clear all buffers before trying to reconnect.


> 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?
>
[Tim] No. It rely on a global based memory protection of the os system.
Let's keep it out of this document so far.

>
> 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 :)
>
[Tim] Agree.

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