rfd

Tue Dec 18 21:32:38 UTC 2018

What would really be of interest to me would be for those that run RFD
to measure its impact to their network (positive or otherwise) so we
have something scientific to base on.

The theory (and practice of old) tells us that RFD is either very good,
or very bad. There are probably more folk that have turned it off than
run it, or vice versa. Ultimately, if we can get the state of RFD's
performance in 2018 on an axis, our words will likely carry more weight.

Mark.

On 18/Dec/18 23:24, Naslund, Steve wrote:
>
> 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/9da7a6c8/attachment.html>