[124268] in North American Network Operators' Group
Re: BGP Update Report
daemon@ATHENA.MIT.EDU (Anton Kapela)
Sun Mar 28 14:01:33 2010
From: Anton Kapela <tkapela@gmail.com>
In-Reply-To: <20100328132943.GB59866@gweep.net>
Date: Sun, 28 Mar 2010 14:00:55 -0400
To: nanog-post@rsuc.gweep.net
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Joe,
> The problem is that unless one is holding customer routes in a=20
> seperate VRF and dampen them there or take similar steps to=20
> segment, dampening leads directly to blackholes. Even in that
> case, failover within that VRF wouldn't work, as all=20
> implementations I've seen attack the prefix as the problem instead
> of the path vector. Bye-bye alternate paths. =20
I guess what I'm hinting at is precisely something finer-grained (path =
not prefix), as you suggest. Per-neighbor enabled, versus "entire bgp =
RIB" would be preferred. I'm also interested in the *chronic* nature of =
these apparent instabilities. An average of one flap per minute could =
imply that the end-site is not getting allot of useful TCP moved, and as =
such, after something on the (n)-hour timescale, perhaps it's worth =
suppressing it.
So, I'd ask for a long-timescale dampening function, indexed against =
per-path, and enforced per neighbor. Perhaps as-path lists could be =
combined with relaxed timers on existing implementations to achieve this =
today (in a VRF target/context).=20
-Tk=
