Why does Sprint have address filters again?

Patrick W. Gilmore patrick at priori.net
Mon Jun 1 18:17:55 UTC 1998


At 08:40 AM 6/1/98 -0700, Roeland M.J. Meyer wrote:

>I agreed to the stipulation, in advance so I wouldn't get lecture #101, yet
>again. The issue here is that ASN's get around prefix filtering, to my
>understanding. If everyone had an ASN then we'd be right back to they
>problem that started prefix filtering in the first place, ever growing, and
>humongous, router tables. Legacy routers have problems with this. 

*sigh*  I will never understand this.  I have ... 'conversed' with Sean and
others at length about this.  Unfortunately, I wasn't running a router with
a full table at the time, so I just don't get it.  Sprint claims to have
this policy for the "good of the Internet".  I find this part particularly
interesting:

<Quote from http://www.sprint.net/filter.htm>

In support of slowing the growth rate of route advertisement within the
Internet, SprintLink filters prefixes from non-customer BGP neighbors
longer than 19 bits in the 206.0.0.0/8 and 207.0.0.0/8 block to the end of
the current range of class C addresses.

</Quote>

I am really puzzled about this.  Based upon the evidence Sean Doran
presented on another list, I did not see any effect on the table from 112.
Specifically, looking at http://www.telstra.net/ops/bgptable.html (part of
said evidence), I see faster growth post-112 than pre-112.  This increase
is immediately apparent after 112's inception, so it's not a "long term"
problem.  I am pretty sure this is not a direct result of 112, but I think
it shows that 112 did not have its intended effect.  So, I guess things
were going on of which I am completely unaware, and which do not show up on
the graph.

As I said, my problem is I just do not see the problems everyone is
complaining about in the data.  Perhaps others who presumably know more
about this than I please comment?

There are a couple things I am sure of.  I am sure Sprint has fewer routes
in their table than other backbones because of 112.  One could argue that
this gives Sprint less, or at least less optimal, connectivity than other
large backbones.  Add the fact that Sprint has not been significantly more
stable than other backbones (there have been accounts on this list of the
opposite in fact, but I am not a Sprint customer, so I have no first hand
knowledge).  One is left wondering why one should use Sprint for transit at
all?

One could also argue that 112 has helped shape the allocation policies of
ARIN and other registries, and one would probably be correct.  I personally
feel using one company, even one as large as Sprint, to define global
allocations policies is a Bad Thing.  Of course, there's nothing I can do
about it anymore.  That is a completely separate topic anyway.

It has been proposed that Sprint's peers filter Sprint with a 112-link
filter, but use their default filters on all other peer/transit
connections.  I would like to see what Sprint's peers have to say about the
possibility of filtering Sprint announcements - and Sprint alone - the same
way Sprint filters their peers.  Sean Donelan at DRA claims he does this,
does anyone else?  Customers and non-peers are also invited to comment.

I personally think this would be an outstanding idea, but I have not looked
at all the things it would break.  Of course, if one is to believe Sprint,
it should break nothing.  Or at least nothing that shouldn't be fixed. ;)

This is especially relevant considering Sean's comments in September of
1995 (while working for Sprint) on this list.  Specifically: "...at some
point we certainly will begin stopping the announcement of this type of
long prefix [longer than /19] to our external peers...".  It's been almost
3 years, one is left to believe that Sprint will never actually do this.
To his credit, Sean also publicly encouraged all Sprint's peers to filter
Sprint.  So at least we know Sean believes in filtering 100%.  But does
Sprint?  Or will the hypocrisy continue?

>Roeland M.J. Meyer, ISOC (InterNIC RM993) 

TTFN,
patrick

**************************************************************
Patrick W. Gilmore                      voice: +1-650-482-2840
Director of Operations, CCIE #2983        fax: +1-650-482-2844
PRIORI NETWORKS, INC.                    http://www.priori.net
              "Tomorrow's Performance.... Today"
**************************************************************



More information about the NANOG mailing list