I will grant you that no customer ever asked for route dampening. I also realize that RFD is much less important now than in the past. I come from the ARPANET/DDN ages of the Internet and can tell you that RFD was absolutely critical in the days of very under powered routers and very unstable data links. I remember when it was quite hard to maintain a 64k link to some locations at all. There might be less of a need for such a simple RFD but it did serve its purpose. In fact, my main argument on this whole topic is that RFD is not relevant enough to waste a lot of effort on a global accepted mechanism. It is just not the low hanging fruit of routing performance improvements. I see two major improvements to global routing...congestion avoidance (which goes a little bit with bandwidth awareness but not exactly) and multipath load balancing (which kind of requires a congestion avoidance awareness). Both of these are going to be extremely difficult issues on a global scale of adoption but that's what is needed.
Steven Naslund Chicago IL >Dear Steve, > >No worries, I have not forgotten the transitive properties of the LOCAL_PREF >BGP Path Attribute! :-) You are right that any LOCAL_PREF modifications (and >the attribute itself), are local to the Autonomous System in which they were >>set, but the effects of such settings can percolate further into the routing >system. > >A great example is the "BGP Graceful Shutdown" mechanism (science partially >documented in https://tools.ietf.org/html/rfc6198, actual specification here >https://tools.ietf.org/html/rfc8326). What is interesting is that by >>considering a path (any path, could be flapping) my network will propagate >alternative paths to my neighboring networks, or possibly even *withdraw* my >announcement in favor of alternative >(stable?) paths via competitors. > >By attaching a lower LOCAL_PREF value to a given path for a period of time as >a 'penalty' for flapping, I suspect the visiblity of that flapping will be >greatly reduced. This of course doesn't hold true when the only origin of the >path is >flapping, but in many flapping cases I triaged it was clear that only >one out of many links was the root of the flapping. > >I'm not sure I share your concerns about scale, it appears that so far we seem >to be doing just fine without "route flap dampening, penalty >type: suppress". No customers ask for it, in fact many are relieved we don't >use it. None of our peering partners ask for it either. When we see >oscillating paths we reach out to the offending party and ask them to fix it, >or take >unilateral action within a specific time frame. > >Kind regards, > >Job
