[195136] in North American Network Operators' Group
RE: Long AS Path
daemon@ATHENA.MIT.EDU (Michael Hare)
Mon Jun 26 11:08:57 2017
X-Original-To: nanog@nanog.org
From: Michael Hare <michael.hare@wisc.edu>
To: Hunter Fuller <hf0002+nanog@uah.edu>, James Bensley <jwbensley@gmail.com>,
"nanog@nanog.org" <nanog@nanog.org>
Date: Mon, 26 Jun 2017 15:08:52 +0000
In-reply-to: <CAMFTxdTwqXkRj7sEOqgsMhvyLJd8r9v5b5mduVTRZPoP=YCXCQ@mail.gmail.com>
Errors-To: nanog-bounces@nanog.org
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).
In the end, it is indeed risk vs reward, with risk being undefined behavior. It's plausible to speculate that not every path length bug has been squashed (or might not be re-introduced).
-Michael
> -----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
>
> This could just be ignorance, but based on this thread, I'm not sure what
> 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).
>
> On Sun, Jun 25, 2017 at 6:32 AM James Bensley <jwbensley@gmail.com>
> wrote:
>
> > On 24 June 2017 at 13:10, Mel Beckman <mel@beckman.org> wrote:
> > > James,
> > >
> > > By "experienced by someone else" I mean someone who is not one of
> your
> > customers.
> > >
> > > 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?
> > >
> > > -mel via cell
> >
> > Hi Mel,
> >
> > 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".
> >
> > Cheers,
> > James.
> >
> --
>
> --
> Hunter Fuller
> Network Engineer
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Systems and Infrastructure
