rfd

Tue Dec 18 22:10:33 UTC 2018

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