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 <[email protected]> > To: Michael Hare <[email protected]> > Cc: Hunter Fuller <[email protected]>, James Bensley > <[email protected]>, "[email protected]" <[email protected]> > Subject: Re: Long AS Path > Message-ID: <[email protected]> > 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 <[email protected]> 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).
