rfd

Tue Dec 18 20:59:45 UTC 2018

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

On Tue, Dec 18, 2018 at 21:56 Naslund, Steve <SNaslund at medline.com> wrote:

> Mainly because propagating a flapping route across the entire Internet is
> damaging to performance of things other your own equipment and that of your
> customer.  It is just "bad manners" to propagate a flapping route to your
> peers and it helps maintain a minimum level of stability that it required
> to keep you "on the Internet".  Imagine a table where 1000s of providers
> are each sending 100s of unstable routes and that those unstable routes
> might be redistributing into various IGPs that may not respond very
> gracefully to rapid table changes (like most distance vector IGPs).  Also
> think of this scenario, your link to your customer might be flapping but
> that same customer might have other carriers advertising the same address
> space over a stable link.  In that case you would be doing a dis-service by
> not withdrawing that route and having a local-pref does not help since you
> don't necessarily have visibility to all of your customers other carrier
> networks.
>
> You do have the ability to clear the RFD timers for a route if you need to
> manually intervene for example when you know for a fact that you fixed the
> problem.  That means that if no one is watching or intervening the network
> will "do the safe thing".
>
> Steven Naslund
> Chicago IL
>
> >
> >I always wondered why does it have to be so binary.
> >
> >I don't want to decide for my customers if partial visibility is better
> than busy CPU, but I do appreciate stability. Why can't we have local-pref
> penalty for flapping route. If it's only option, keep offering it, if there
> are other, more >stable options, offer those.
> >
> >--
> >  ++ytti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181218/0bd4eced/attachment.html>