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
___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
