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