Long AS Path

Mon Jun 26 16:27:39 UTC 2017

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 at 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 at nanog.org] On Behalf Of Hunter
>> Fuller
>> Sent: Monday, June 26, 2017 9:40 AM
>> To: James Bensley <jwbensley at gmail.com>; nanog at 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 at gmail.com>
>> wrote:
>> 
>>>> On 24 June 2017 at 13:10, Mel Beckman <mel at 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