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

From: Tim <[email-masked]>
Date: Fri, 28 Dec 2018 15:52:39 +0800

Dear authors,

I just read the draft and glad to see someone standout and proposing 
solutions on problem I ever suffered.

I have some comments on this draft and hope they help.

1. Related with Considerations for soft thresholds

Actually the behavior after reaching threshold include:

Soft limit:

1) Alert only: Only alert triggered, neighbor is not impacted

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

Hard limit:

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

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.

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.

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.

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.

5. In the last, related with Implementation status:

I can provide implementation status on Huawei devices:

latest VRPV8: support both type a and type b, no support for outbound 
prefix limit

type A: peer route-limit

type B: peer route-limit accept-prefix

Legacy VRPV5, only type A supported (peer route-limit)

Finally thanks for the draft again.

Regards,

Tim

---

From: heasley <[email-masked]>
Date: Fri, 28 Dec 2018 17:13:19 +0000

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

unless it repeats the alert for every bgp packet received with announcement
nlri (log coalescing/throttling permitted), that sounds like a terrible
action.  I expect that otherwise the event might (will) pass unnoticed.

> protection mechanism is needed.

seems to be common sense and out of scope.