rfd

Tue Dec 18 21:24:09 UTC 2018

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181218/ff91cf68/attachment.html>