Re: Long AS Path

["Jakob Heitz (jheitz)" <jheitz () cisco com>]

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).