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 <m...@beckman.org> > To: Michael Hare <michael.h...@wisc.edu> > Cc: Hunter Fuller <hf0002+na...@uah.edu>, James Bensley > <jwbens...@gmail.com>, "nanog@nanog.org" <nanog@nanog.org> > Subject: Re: Long AS Path > Message-ID: <5cc4ba8e-8fbf-4ad4-835d-2c06265ce...@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.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).
