The reason that a private ASN in the public routing table is an error is that the AS Path is used to prevent loops. You may have private AS 65000 in your organization and I may have another private AS 65000 in my organization. If my ASN 65000 is in the AS path of a route sent to you, then your AS 65000 will drop it, thinking it were looping back. BTW, this is different from a confederation member AS. Thanks, Jakob.
Date: Mon, 26 Jun 2017 16:27:39 +0000 From: Mel Beckman <mel@beckman.org> To: Michael Hare <michael.hare@wisc.edu> Cc: Hunter Fuller <hf0002+nanog@uah.edu>, James Bensley <jwbensley@gmail.com>, "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Long AS Path Message-ID: <5CC4BA8E-8FBF-4AD4-835D-2C06265CE502@beckman.org> Content-Type: text/plain; charset="us-ascii"
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).