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