North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Sprint's filtering

  • From: I Am Not An Isp
  • Date: Wed Oct 07 20:50:19 1998

At 04:07 PM 10/7/98 -0700, David R. Conrad wrote:
>Hi,
>
>>if you have some *facts* to present, please
>>feel free to send them my way.
>
>Fact:  the existence of documented filters imposed by Sprint was and is
>used by the Internet registries (well, at least one I'm positive about) to
>discourage the allocation of provider independent prefixes.

I have been told that ARIN did make an effort to have Sprint remove its
filter so that ARIN could allocate blocks longer than /19, but I have not
confirmed this with ARIN.  In any event, I do not dispute that Sprint's
filters had at least some affect on the allocation policies of ARIN.  So
we'll count this as a fact barring a denial from ARIN.

>Did this "save the Internet"?  First, you have to figure out what it means
>for the Internet not to be "saved".  In this context, I'd argue it would
>mean portions of the Internet would become unreachable because routers
>couldn't handle the routing load.  The Internet would not have collapsed --
>service providers would take whatever steps they felt necessary to provide
>the highest level of service they were able to please the largest portion
>of their customers.  In practice, I suspect this would mean they would (you
>guessed it) filter out long prefixes.  

While I agree that unchecked growth of the table will likely lead to Bad
Things, I'm simply stating that we are incapable of *knowing* the table
would not have found some better way of regulating itself had 112 not been
implemented.  Perhaps people would have tried harder to aggregate.  Perhaps
people would have filtered only those providers who did not aggregate.
Perhaps cisco and the other vendors would have come out with bigger,
better, faster, cheaper routers sooner.  Who knows?  Certainly not me, and,
unless you have some mystical powers, neither do you.

>So the question really is, did Sprint's filters reduce the rate of growth
>of the Internet routing system.  Clearly, given the registries did not
>allocate some prefixes they would have had otherwise, the answer is yes.
>Would the Internet have partitioned if Sprint didn't impose the filters?
>Dunno.  I do know that the number of provider independent prefixes at least
>one registry allocated dropped significantly after the filters were turned
on.

Your assumption does not guarantee your conclusion in any way.  Clearly, if
the registries had decided to allocate smaller blocks, we would have some
routes in the table which we currently do not have.  This does not prove
the size of the table as a whole would be bigger, smaller or the same as it
is now.  It's a reasonable guess, but that's all it is.

Here's what facts I do have regarding 112.  When Sean and I first had this
argument, he posted several URLs showing graphs over the last few years of
the size of the table.  I'm afraid that other than a small dip in when the
filters were implemented, I see little to no change in the actual growth
rate due to 112's implementation.  In fact, right after that short, small
dip, the rate of growth actually increases slightly.

Now, unless you are going to claim Sean is a fortune teller and knew that
the growth rate would skyrocket right at that time, it is obvious that 112
did not have its intended effect.

Going back to your idea about the allocations from the registries.  How
many of you go "I can't announce that because Sprint won't hear it?"  I
almost never hear that.  Everyone just assumes the aggregate CIDR allocated
from ARIN (or wherever) will be announced and whoever announces the more
specific expects the provider announcing the aggregate to pass the packet
along.  Unless, of course, the provider announcing the aggregate is Sprint.
 So, if anything, Sprint's filters tend to create a bit of suboptimal
routing, not slow the table growth.  It may even be argued that the number
of announcements has *increased* due to 112 - because we now have the
downstream announcing their tiny block and the upstream announcing the full
allocated CIDR.  Perhaps if each downstream were allocated their own block,
we could remove some of the CIDR announcements and shrink the table?


But that's academic now.  Besides, I'm still not saying that Sprint has to
remove their filters - it's their network, they can filter as they please.
In fact, even I believe Sprint's filters have some effect on the table - at
least initially.  I just think the overall effect is less than everyone
else seems to think.  I also believe that there are other, more useful ways
of shrinking the table - such as forcing people to aggregate.

My main point was that Sprint *does* enjoy a competitive advantage with 112
- but only because we let them.  Whether they did it for altruism (yeah,
right, even Sean doesn't say that), or because they had to 'cause their own
equipment couldn't handle it (as Sean claims), they probably get some
business because of those filters.  But that advantage would evaporate if
everyone filtered Sprint the same way.  (It would actually be a
disadvantage if everyone filtered Sprint *and only Sprint* in that way.)

So, let's assume filtering is really that awesome and absolutely necessary
for the good of the Internet.  I propose we try a test case to prove this
hypothesis.  Everyone filter Sprint.  It's quite easy, Sean posted some
versions of 112 to NANOG back in September of 1995.  (See
http://www.ianai.net/filters/Sprint-ACL112 for one of his early versions.)

I said before it was difficult to test, but I think this may provide a
valid measurement.  If Sprint is not a large enough provider to make
filtering them sadistically significant, then their continued use of 112 is
useless with regards to slowing the growth of the table.  (Can't have it
both ways.)

So, anyone care to filter Sprint with a 112-like ACL?

>-drc

TTFN,
patrick