[195137] in North American Network Operators' Group
Re: Long AS Path
daemon@ATHENA.MIT.EDU (Mel Beckman)
Mon Jun 26 12:27:51 2017
X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Michael Hare <michael.hare@wisc.edu>
Date: Mon, 26 Jun 2017 16:27:39 +0000
In-Reply-To: <CY4PR06MB2853975028A55FB1250B8DF9F9DF0@CY4PR06MB2853.namprd06.prod.outlook.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
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 clea=
r error, so filtering them is reasonable. Long AS paths are not a clear err=
or.'
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.=20
Until somebody does that, I don't see long path filtering as morally defens=
ible :)
-mel beckman
> On Jun 26, 2017, at 8:09 AM, Michael Hare <michael.hare@wisc.edu> wrote:
>=20
> Couldn't one make the same argument with respect to filtering private ASN=
s from the global table? Unlike filtering of RFC1918 and the like a privat=
e 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 a=
go on NANOG.
>=20
> 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 r=
oute, in the end costing me money (choosing transit vs peering).
>=20
> In the end, it is indeed risk vs reward, with risk being undefined behavi=
or. It's plausible to speculate that not every path length bug has been sq=
uashed (or might not be re-introduced).
>=20
> -Michael
>=20
>> -----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
>>=20
>> This could just be ignorance, but based on this thread, I'm not sure wha=
t
>> 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).
>>=20
>> On Sun, Jun 25, 2017 at 6:32 AM James Bensley <jwbensley@gmail.com>
>> wrote:
>>=20
>>>> On 24 June 2017 at 13:10, Mel Beckman <mel@beckman.org> wrote:
>>>> James,
>>>>=20
>>>> By "experienced by someone else" I mean someone who is not one of
>> your
>>> customers.
>>>>=20
>>>> 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?
>>>>=20
>>>> -mel via cell
>>>=20
>>> Hi Mel,
>>>=20
>>> 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".
>>>=20
>>> Cheers,
>>> James.
>> --
>>=20
>> --
>> Hunter Fuller
>> Network Engineer
>> VBH Annex B-5
>> +1 256 824 5331
>>=20
>> Office of Information Technology
>> The University of Alabama in Huntsville
>> Systems and Infrastructure
