Re: Long AS Path

[Mel Beckman <mel () beckman org>]

Michael,

Filtering private ASNs is actually part of the standard. It's intrinsic in the term "private ASN". A private ASN in the 
public routing table is a clear error, so filtering them is reasonable. Long AS paths are not a clear error.'

I'm surprised nobody here who complains about long paths is has followed my suggestion: call the ASN operator and ask 
them why they do it, and report the results here. 

Until somebody does that, I don't see long path filtering as morally defensible :)

 -mel beckman

> On Jun 26, 2017, at 8:09 AM, Michael Hare <michael.hare () wisc edu> wrote:
>
> 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