Long AS Path

Thu Jun 22 11:27:35 UTC 2017

On Wed, 21 Jun 2017, Saku Ytti wrote:

> Hey,
>
> Uou're saying, you drop long AS_PATH, to improve customer observed
> latency? Implication being, because you dropped the long AS_PATH
> prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?
>
> Absent of this policy, in which scenario would you have inserted the
> filtered longer AS_PATH prefix to the FIB? I assume only scenario
> where this happens is where there is larger aggregate route, which is
> lower latency than the more specific route with longer as_path.

You do have to wonder, what was the thought process that resulted in 35
being the right number of prepends "accomplish" whatever TE they were
shooting for?

AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644
55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
55644 55644 55644 45271

I don't mean to single out 55644.  It's just the first/most obnoxiously
long as-path I found when looking for long ones.

I seriously doubt provider/customer/customer-of-customer relationships 
ever get much deeper than a handful or so of ASNs...so if prepending a few 
times doesn't get it done, 10-20-30 prepends are unlikely to help.

In the above case, that long path is actually our best path.  We localpref 
peering above transit.  So, it doesn't matter how many prepends, they add, 
we're never going to not use this path if its available.  We have transit 
paths to these routes that are only a single handful of ASNs long.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
                              |  therefore you are
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________