Michael Dillon wrote: | The policies that once were technical policies instituted | by Sean Doran are no longer technical policies but a crass manipulation of | the marketplace to Sprint's advantage as the archives of this list prove | quite amply. Hello, my name is Sean Doran. The reality you seem to forget is that Sprint's holding the line on filtering has been holding the number of prefixes being seen globally to a conveniently small number. Just as the several networks who refuse to listen to announcements of address space not delegated by the IP registries -- or recorded in routing registries as associated with the origin AS -- Sprint's filtering has done some public good as a side-effect of intelligent self-defensive design. A denial of that is merely petty politicking, rather than anything actually rooted in technical issues. Finally, unlike a number of people reading this message, Sprint was largely unaffected by the unfortunate leak of several thousand prefixes by another large provider in the not-too-distant past. On that note, should someone go mad and decide to deaggregate a /8 to the /32 level just for fun, how many of you honestly wouldn't notice because you have *some* sort of prefix-length filtering in place? I'm curious to know in your particular case, Michael, whether you have a concern about the actual act of self-defensive filtering, or whether you are merely arguing that the potential number of prefixes Sprint may see is too low. Oh, wait, you wave the spectre of "clear violation of antitrust" around, so therefore any claim that you are making a _technical_ argument is clearly false. So, I am sure you are unimpressed that I actually hope Sprint undertakes to do *more* filtering, namely to ensure that prefixes can only be originated by ASes to whom the registries have delegated the address space, using a scheme proposed by Tony Li, Yakov Rekhter and Randy Bush, as presented at NANOG and RIPE and in other venues. That they protect themselves and their customers from unintentional routing-table explosions and redistributions into and out of IGPs does some public good is a useful side-effect, but the primary goal is and ought to be self-protection. | But I want to know | why ARIN cannot simply issue an appropriately sized portable block of | addresses to anyone who is legitimately multihomed? Appropriately sized: one /32, please. Legitimately multihomed: I have accounts at two ISPs in Toronto, one ISP in Copenhagen, and two ISPs in Stockholm. I also travel to IETFs and other places with terminal rooms, and would dearly like my laptop never to have to renumber when it changes its location in the topology. My laptop's *users* moreover would really hate to have to adapt to changing IP addresses every time a new provider gets selected. Please campaign for *MY* rights, too, you guys! I feel left out by you big boy regional ISPs who are trying to strangle my enterprise out of existence with your antitrust policies favouring the large and medium-sized over the very small! Sean.
At 06:59 AM 10/07/1998 -0700, Sean M. Doran wrote:
Legitimately multihomed: I have accounts at two ISPs in Toronto, one ISP in Copenhagen, and two ISPs in Stockholm. I also travel to IETFs and other places with terminal rooms, and would dearly like my laptop never to have to renumber when it changes its location in the topology.
Sorry. While we've indeed built a system which provides mobility for Internet engineers, that only refers to *job* mobility... ;-) /John
On Wed, Oct 07, 1998 at 06:59:35AM -0700, Sean M. Doran wrote:
Appropriately sized: one /32, please. Legitimately multihomed: I have accounts at two ISPs in Toronto, one ISP in Copenhagen, and two ISPs in Stockholm. I also travel to IETFs and other places with terminal rooms, and would dearly like my laptop never to have to renumber when it changes its location in the topology.
My laptop's *users* moreover would really hate to have to adapt to changing IP addresses every time a new provider gets selected.
Both AT&T and GTE now offer flat rate Internet access via CDPD. Modems are available in a type-3 P-card form factor for about $7-800. Service is $54,95 a month, AT&T will offer off-net roaming at a flat rate for an additional $10/month. Anything else I can help you with? :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
At 06:59 AM 10/7/98 -0700, Sean M. Doran wrote:
Michael Dillon wrote:
| The policies that once were technical policies instituted | by Sean Doran are no longer technical policies but a crass manipulation of | the marketplace to Sprint's advantage as the archives of this list prove | quite amply.
Hello, my name is Sean Doran.
Howdy Sean. Long time no see. :p
The reality you seem to forget is that Sprint's holding the line on filtering has been holding the number of prefixes being seen globally to a conveniently small number.
While this *may* have been true in circa 1995, there is little to no evidence that 112 is still performing the same service. If you want a "technical" argument, Sean, stick to the *facts*, not your assumptions. To be blunt, it is impossible to tell what would really have happened had those filters not been in place for the last few years. Or are you going to claim some Carnak like powers to predict what a system as large and complex as the Internet would do without your sage guidance over a period of years? Unfortunately, about the only way to "test" it is to take the filters off. Fortunately, most providers out there ignore Sprint's filters because an aggregate is being announced by their upstream and they'll get the packets eventually. Personally, I think a far larger gain could be made by searching out all the people who are announce sub-blocks of their own CIDR from their own ASN. While doing this can provide some utility to your peers (e.g. more accurate MEDs), the overwhelming majority of people announcing a sub-section of their own CIDR are doing it ... by accident. (At least I hope it is by accident. :) Add to that some aggregation effort (two /18s into one /17, etc.) and the table would probably shrink quite a bit more than under the effect of Sprint's filters. Of course, that's just my opinion. :-) The good thing is, the amount of shrinkage from my suggestion can be calculated fairly easily. Mr. Rand at Above.Net once ran a script which showed such calculations and there are things like the CIDR report which show large amounts of deaggregation by some large providers. (I seem to recall one of Sprint's networks being pretty hi up on that list until recently. :) Perhaps we should spend some time LARTing those who do not aggregate properly?
Just as the several networks who refuse to listen to announcements of address space not delegated by the IP registries -- or recorded in routing registries as associated with the origin AS -- Sprint's filtering has done some public good as a side-effect of intelligent self-defensive design.
A denial of that is merely petty politicking, rather than anything actually rooted in technical issues.
[SNIP] Actually, Sprint's policy is partially motivated by "politicking" - or at least by capitalistic goals. Since you have personally admitted this to my face, and Sprint's management has said as much in private e-mail, I think you calm down on the name calling. If Sprint were *truly* out for the "good of the Internet", then they would filter their downstreams the same way they filter their peers. But for some unknown reason, I see all kinds of small blocks coming out of Sprint. For instance: *>i136.150.45.0/24 X.X.X.X 169 100 0 1239 1785 i *>i136.150.46.0/24 X.X.X.X 169 100 0 1239 1785 i *>i136.150.60.0/24 X.X.X.X 169 100 0 1239 1785 i [...] *>i168.167.25.0/24 X.X.X.X 169 100 0 1239 4005 ? *>i168.167.26.0/24 X.X.X.X 169 100 0 1239 4005 ? *>i168.167.27.0/24 X.X.X.X 169 100 0 1239 4005 ? *>i168.167.28.0/24 X.X.X.X 169 100 0 1239 4005 ? [...] *>i208.14.160.0 X.X.X.X 169 100 0 1239 4997 i *>i208.14.161.0 X.X.X.X 169 100 0 1239 4997 i * i208.14.162.0 X.X.X.X 189 100 0 1239 4997 i *>i208.14.163.0 X.X.X.X 169 100 0 1239 4997 i [...] (I've obviously edited it a bit, but it's easy enough for anyone here to check this information at any of the public route servers.) So Sprint obviously has some agenda besides "the good of the Internet" or "the size of the table". Or they at least realize some benifit, financial or otherwise, from not practicing what they preach. Now please don't flame me saying Sprint can do as it pleases. I completely agree that Sprint is allowed to filter whomever they want whenever they want. (As long as the filters don't break any contracts, etc.) If a customer doesn't like it, they can move. I just have a problem with Sprint saying "we're here to save the Internet" and then doing *exactly* what they claim others should not be doing. Hypocrisy annoys me. Of course, publicly Sprint blames this on their peers. You see, they say their peers should filter Sprint the same way Sprint filters their peers. So, let's take them up on it. If you honestly believe Sprint is getting some advantage out of filtering you, then FILTER THEM BACK. But be sure to only filter Sprint. :p If everyone - or even just a couple really big providers - did this, Sprint would suddenly lose its "advantage". All those people who bought a T1 into Sprint so their /24 would be seen globally will be pretty upset when it was not being seen by, say, UUNET. Unfortunately, the large backbones don't have the ... backbone to do this. (Sorry about the pun, I couldn't resist. :) It's really a shame. Sprint is no longer even close to the largest backbone out there, so people don't have to bow and scrape at their whim. But they've already taken the heat for instituting filters, and no one else wants to do the same. (I gotta admit, Sean, it took balls to do that - even if you were the biggest back then.) Anyway, I'll prolly get flamed for this by all kinds of people saying "of COURSE the table would be out of control without Sprint's help!" But that's okay, I'm used to flames. Sean's own evidence didn't show me anything I would call even close to "proof" that 112 is saving the Internet, so anyone just "claiming to know" 'cause they have been around longer than me, or they run this network, or they work for this vendor, or even they are psychic probably isn't going to sway me. Unsubstantiated claims are worthless. OTOH, if you have some *facts* to present, please feel free to send them my way.
Sean.
TTFN, patrick
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. 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. 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. Regards, -drc
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
On Wed, Oct 07, 1998 at 04:07:17PM -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.
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.
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.
Regards, -drc
Balderdash. The cost of a few SIMMs in routers pales beyond the market damage that comes from not being able to get where your customers want to go. Protecting provider's hardware budgets is not part of a registry's job. -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization.
On Thu, 8 Oct 1998, Karl Denninger wrote:
Balderdash. The cost of a few SIMMs in routers pales beyond the market damage that comes from not being able to get where your customers want to go.
Protecting provider's hardware budgets is not part of a registry's job.
I don't think the cost of having enough memory was the issue, it was the physical ability of the router's cpu to handle updating the routing table with that many routes... Sean Mentzer Qwest Communications IP Engineering 303-226-6770
At 09:27 AM 10/8/98 -0600, Me wrote:
On Thu, 8 Oct 1998, Karl Denninger wrote:
Balderdash. The cost of a few SIMMs in routers pales beyond the market damage that comes from not being able to get where your customers want to go.
Protecting provider's hardware budgets is not part of a registry's job.
I don't think the cost of having enough memory was the issue, it was the physical ability of the router's cpu to handle updating the routing table with that many routes...
The key word is "was". Since then, Moore's Law has taken us to routers that can handle the load better. ___________________________________________________ Roeland M.J. Meyer, ISOC (InterNIC RM993) e-mail: <mailto:rmeyer@mhsc.com>rmeyer@mhsc.com Internet phone: hawk.mhsc.com Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer Company web-site: <http://www.mhsc.com/>www.mhsc.com/ ___________________________________________ I bet the human brain is a kludge. -- Marvin Minsky
On Thu, Oct 08, 1998 at 09:27:21AM -0600, Me wrote:
On Thu, 8 Oct 1998, Karl Denninger wrote:
Balderdash. The cost of a few SIMMs in routers pales beyond the market damage that comes from not being able to get where your customers want to go.
Protecting provider's hardware budgets is not part of a registry's job.
I don't think the cost of having enough memory was the issue, it was the physical ability of the router's cpu to handle updating the routing table with that many routes...
Sean Mentzer Qwest Communications IP Engineering 303-226-6770
Aggressively dampening flaps solves that problem. Entropy is controllable; the issue was presented as being one of table space (much as it was when the AGS+ ran out of space until the 7000/SSP was introduced) -- -- Karl Denninger (karl@denninger.net) http://www.mcs.net/~karl I ain't even *authorized* to speak for anyone other than myself, so give up now on trying to associate my words with any particular organization.
On Thu, 8 Oct 1998, Me wrote:
On Thu, 8 Oct 1998, Karl Denninger wrote:
I don't think the cost of having enough memory was the issue, it was the physical ability of the router's cpu to handle updating the routing table with that many routes...
It was RAM and CPU IIRC - but both aren't the same issue as they were then - speeds have factored up a bit too -- I am nothing if not net-Q! - ras@poppa.clubrich.tiac.net
it is impossible to tell what would really have happened had those filters not been in place for the last few years.
one can truely not tell about alternate futures, i.e. mci would probably be filtering, as they were pretty ram short. but those interested in data as opposed to cheap talk might look at frank's measurement reports to ale and cidrd. randy
Actually, Sprint's policy is partially motivated by "politicking" - or at least by capitalistic goals. Since you have personally admitted this to my face, and Sprint's management has said as much in private e-mail, I think you calm down on the name calling.
You know I don't usually bother to add to the ranting on this list, but please forward said private email from Sprint management. As one who was formerly responsible for this policy as a Sprint Engineer I find it impossible for you to have said mail. There are many reasons for this, none of which I care to go into. Produce it please. Jonathan Gardner
Actually, Sprint's policy is partially motivated by "politicking" - or at least by capitalistic goals. Since you have personally admitted this to my face, and Sprint's management has said as much in private e-mail, I think you calm down on the name calling.
You know I don't usually bother to add to the ranting on this list, but
At 12:35 AM 10/8/98 -0400, Babylon Sigma wrote: please
forward said private email from Sprint management. As one who was formerly responsible for this policy as a Sprint Engineer I find it impossible for you to have said mail. There are many reasons for this, none of which I care to go into. Produce it please.
As it was a private e-mail, I will politely turn you down. I will, however, tell you that it happened this year (1998), during an exchange on NANOG much like the one we are currently having. If you don't believe me, I completely understand. Feel free to disregard that portion of my statement as I probably should not have said anything anyway, since it was sent in confidence. However, the discussion between Sean and I was in the lobby at the last NANOG and was witnessed by many people. Feel free to ask about that. BTW, since you were part of the original decision process, are you telling me that Sprint did not at any time consider any financial impact these filters might have? If so, that's actually worse (IMHO) than doing it solely to get money. This may be the Internet, but (as I have found out personally of late ;), if you don't make money, you don't stay in business. The point is not really whether Sprint did it because it gives them an advantage. The point is that it DOES give Sprint the advantage, and they know it (or at least they should, if you wish to disregard my claims), yet Sean and Sprint still act publicly as if they are guardians of the route table and without their wisdom and restraint, the rest of us would all die horrible deaths. Thanx, but I prefer the cash motive if you're gonna pull something like that. Then to add insult to injury, the only reason they enjoy a continued advantage is because *we let them*. This is what has me totally befuddled. Any Sprint peers care to explain why they do not filter Sprint in the same way Sprint filters them?
Jonathan Gardner
TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle
a critical difference should be noted between hearsay, conjecture, sensationalist invective, etc. and actual memory and written record of those who were there. randy
participants (11)
-
Babylon Sigma -
David R. Conrad -
I Am Not An Isp -
Jay R. Ashworth -
John Curran -
Karl Denninger -
Me -
Randy Bush -
Rich Sena -
Roeland M.J. Meyer -
Sean M. Doran