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