RE: rfd

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

Remember always that the local pref is just that, YOUR local preference.  Sending that flapping route upstream does not 
give your peer the option to ignore it.  In any case, the downside is that you have to process that route and then 
choose whether or not to use it.  It’s like saying “now that you have processed this unstable route and burned your CPU 
cycles, I am now giving you to option not to install it into your table”.  Remember also that we are only talking about 
default behavior here.  You always have the option to override it by changing timer, penalties, or shutting down RFD 
all together.  We are only talking about day-to-day operation here.

Also, keep in mind that when we are talking about alterative stable paths we are only talking about what your network 
sees, not the entire Internet.  If you as a service provider are experiencing major issues, you may see a route to me 
as stable or unstable but making global routing decisions based on that is not sound.  What might be best for your 
customer or your business might not be best for the Internet community as a whole.   It is a matter of scale, how many 
services providers can allow how many unstable routes before the entire network becomes regionally or globally 
unstable.  It’s important to remember that flapping routes leave a certain amount of data in flight with no destination 
which is detrimental to overall performance.  As we move into a V6 world we are again worried about the size of the 
global routing tables and pushing routing performance.  Instability of routes is dangerous to system running near the 
limits.  Propagating a known unstable route would be a major shift in routing policy.  Today, you either say you can 
reach something or you don’t say anything.  Using the suggested alternative adds the option of “I might be able to 
reach this but not reliably” which then brings about metrics of “how reliably?” and that is a huge shift in how global 
routing works.  We have been struggling with a backbone routing protocol that does not really do a good job of 
understanding bandwidth and multiple paths so I would suggest that adding “maybe” routes is not a good idea.
At least using RFD you can explain to your customer why they are not reachable rather than explaining how you made a 
manual decision to dump them for the “good of the Internet”.  There is also a business penalty to the service provider 
that exposes instability to network.  People don’t want to peer or send traffic through unstable network regions.

Steve


> Hi Steve,
>
> Lowering the LP would achieve the outcome you desire, provided there are (stable) alternative paths.
>
> What you advocate results in absolute outages in what may already be precarious situations (natural disasters?) - what 
> Saku Ytti suggests like a less painful alternative with desirable properties.
>
> Kind regards,
>
> Job