RE: rfd

["Naslund, Steve" <SNaslund () medline com>]

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