RE: Long AS Path

[Michael Hare <michael.hare () wisc edu>]

Couldn't one make the same argument with respect to filtering private ASNs from the global table?  Unlike filtering of 
RFC1918 and the like a private ASN in the path isn't likely to leak RFC1918 like traffic, yet I believe several major 
ISPs have done just that.  This topic was discussed ~1 year ago on NANOG.

I do filter private ASNs but have not yet filtered long AS paths.  Before I did it I had to contact a major CDN because 
I would have dropped their route, in the end costing me money (choosing transit vs peering).

In the end, it is indeed risk vs reward, with risk being undefined behavior.  It's plausible to speculate that not 
every path length bug has been squashed (or might not be re-introduced).

-Michael

> -----Original Message-----
> From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of Hunter
> Fuller
> Sent: Monday, June 26, 2017 9:40 AM
> To: James Bensley <jwbensley () gmail com>; nanog () nanog org
> Subject: Re: Long AS Path
>
> This could just be ignorance, but based on this thread, I'm not sure what
> risk we would be managing, as DFZ router operators, by filtering those
> paths. They seem silly, but harmless (similar to, for instance, painting a
> nyan cat on a graph by announcing prefixes at certain times).
>
> On Sun, Jun 25, 2017 at 6:32 AM James Bensley <jwbensley () gmail com>
> wrote:
>
> > On 24 June 2017 at 13:10, Mel Beckman <mel () beckman org> wrote:
> > > James,
> > >
> > > By "experienced by someone else" I mean someone who is not one of
> your
> > customers.
> > > The better strategy, I think, is to not filter long paths unless you
> > have a reason to see their creating a problem. Otherwise you're just
> > operating on superstition, no?
> > > -mel via cell
> >
> > Hi Mel,
> >
> > I mean this as a rhetorical question as we could talk until the end of
> > time about this; what is the difference between operating on
> > superstition and trying to be pro-active? Both for me fall under the
> > category of "risk management".
> >
> > Cheers,
> > James.
> --
>
> --
> Hunter Fuller
> Network Engineer
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Systems and Infrastructure