RE: Why does Sprint have address filters again?
Suggestion: The initial ASN should be bundled with a /19 to create a "multi-home" package. Unbundled ASNs whould be unreasonably high to cover the administration of the initial ASNs of the world, and the cost associated with a /19. In reality it seems you need both, a /19 to make it past the route filters, and an ASN. This also save on the ARIN support side, since the ARIN employee tasked with making the call to verify the customer does in fact have 2 T-1s (or has 2 ISPs vouch he will have at least a T1 with each), can also verify they will accept the routes for the ASN. Seems like this would cut the administraion on ARIN's behalf a bit, and make it "more fair" to the smaller networks looking to multi-home (See Karl's proposal on IP allocation). -jamie@networked.org -----Original Message----- From: Michael Dillon [mailto:michael@memra.com] Sent: Saturday, May 30, 1998 12:02 AM To: nanog@merit.edu Cc: arin-council@arin.net Subject: Re: Why does Sprint have address filters again? On Fri, 29 May 1998, Karl Denninger wrote:
Now, let's look at the parallels:
1. Both are required to "do business" in a given sector (ie: announce routes, sell to the Erate customer base)
2. Both are simple *technical* providers (assignment of a number, with the important being that it is unique in both cases).
3. One is free to the ISP.
4. The other costs $500.00
5. One is financed by the government out of your taxes and is merely an accounting formality much like a customer ID number. The other is funded by a corporation that has no government funding and must support itself not unlike most businesses and the number is a critical infrastructure identifier something like an NPA-NXX.
What is going on here? ASNs didn't used to cost money until ARIN got its claws into them.
ASNs have always cost money to issue. It's just that in the past it was funded out of taxes funnelled through the NSF to a subcontractor and hidden somewhere in NSI's budget. Those days are gone, thank God. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
This does make sense - a lot of sense. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Sat, May 30, 1998 at 12:26:31AM -0400, Jamie Scheinblum wrote:
Suggestion:
The initial ASN should be bundled with a /19 to create a "multi-home" package. Unbundled ASNs whould be unreasonably high to cover the administration of the initial ASNs of the world, and the cost associated with a /19.
In reality it seems you need both, a /19 to make it past the route filters, and an ASN. This also save on the ARIN support side, since the ARIN employee tasked with making the call to verify the customer does in fact have 2 T-1s (or has 2 ISPs vouch he will have at least a T1 with each), can also verify they will accept the routes for the ASN.
Seems like this would cut the administraion on ARIN's behalf a bit, and make it "more fair" to the smaller networks looking to multi-home (See Karl's proposal on IP allocation).
-jamie@networked.org
-----Original Message----- From: Michael Dillon [mailto:michael@memra.com] Sent: Saturday, May 30, 1998 12:02 AM To: nanog@merit.edu Cc: arin-council@arin.net Subject: Re: Why does Sprint have address filters again?
On Fri, 29 May 1998, Karl Denninger wrote:
Now, let's look at the parallels:
1. Both are required to "do business" in a given sector (ie: announce routes, sell to the Erate customer base)
2. Both are simple *technical* providers (assignment of a number, with the important being that it is unique in both cases).
3. One is free to the ISP.
4. The other costs $500.00
5. One is financed by the government out of your taxes and is merely an accounting formality much like a customer ID number. The other is funded by a corporation that has no government funding and must support itself not unlike most businesses and the number is a critical infrastructure identifier something like an NPA-NXX.
What is going on here? ASNs didn't used to cost money until ARIN got its claws into them.
ASNs have always cost money to issue. It's just that in the past it was funded out of taxes funnelled through the NSF to a subcontractor and hidden somewhere in NSI's budget. Those days are gone, thank God.
-- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael@memra.com http://www.memra.com - *check out the new name & new website*
At 01:27 AM 5/30/98 -0500, Karl Denninger wrote:
This does make sense - a lot of sense.
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
On Sat, May 30, 1998 at 12:26:31AM -0400, Jamie Scheinblum wrote:
Suggestion:
The initial ASN should be bundled with a /19 to create a "multi-home" package. Unbundled ASNs whould be unreasonably high to cover the administration of the initial ASNs of the world, and the cost associated with a /19.
In reality it seems you need both, a /19 to make it past the route filters, and an ASN. This also save on the ARIN support side, since the ARIN employee tasked with making the call to verify the customer does in fact have 2 T-1s (or has 2 ISPs vouch he will have at least a T1 with each), can also verify they will accept the routes for the ASN.
Seems like this would cut the administraion on ARIN's behalf a bit, and make it "more fair" to the smaller networks looking to multi-home (See Karl's proposal on IP allocation).
-jamie@networked.org
No, it does not make a lot of sense. In fact, IMHO, this is a very, *very* bad idea. Remember what we are trying to conserve here - not just ASNs, but IP Space too. Making unbundled ASNs "unreasonably high" would kill all the people who are being good little businesses and conserving IP space. For instance, what do you say to the large corporation who wants the redundancy of two connections, but uses NAT or DHCP so they only need a /23 or /22? And what do you say to the web farm that uses HTTP 1.1 to conserver IP space but who's customers demand redundancy or low latency to several networks? There are many, many more instance of perfectly legitimate uses for an ASN with less than a /19. As for the "filtering" issue, well, Sean and I have had words over that before. The large majority of my customers multi-home, and less than a third of those have (or need) their own /19. They are aware than they'll only get Sprint & AGIS traffic from my network (because I announce the whole CIDR), and that if my T1 drops the packet will go from Sprint to Priori to their other upstream in a round-a-bout fashion. But they generally feel this is an acceptable penalty to pay for the conservation of IP space. Are you suggesting that we penalize these people even more for doing the "right thing"? The could drop all those conservation tactics and say they "need" a /19, thereby depleting the v4 space that much sooner - which I'm sure they'd do if you made the price "unreasonably high". On the flip side, charging more (a lot more) for 2nd, 3rd, etc. ASNs sounds fine to me. Admittedly, I have not thought the whole thing through since neither I nor any of my downstreams use multiple ASNs, so I might be missing something. Feel free to correct me. It just seems to me that multiple ASNs *might* be necessary in some instances - like when multiple countries are covered under one network. But in the overwhelming majority of cases, it seems that things like BGP confederations could be used internally for anything that required multiple ASNs, while letting the rest of the 'Net see just one ASN. Sprint, for instance, has many, many ASNs. Considering their (Draconian? ;) policy of conservation wrt IP space, why do they suddenly need dozens of ASNs? For the record, I do not think the $500 one-time fee is completely ridiculous. It might be lowered, but it's not nearly as outrageous as some people are suggesting - IMHO. And I really don't see how $30/year can be considered usury by anyone. Unless you would rather bill people on a "per query" basis or something? Say $0.01 per "whois"? Or something equally silly and ridiculously difficult to collect, bill, deal with delinquencies, etc., etc. Now the schedule of $5,000 per year just to have a block of space which is capable of passing those filters we talked about.... Well, let's just say that I'm not completely satisfied this is as reasonable. Especially considering it is an annually recurring charge, unlike the $500 ASN fee. 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" **************************************************************
On Sun, May 31, 1998 at 12:30:46AM -0700, Patrick W. Gilmore wrote:
At 01:27 AM 5/30/98 -0500, Karl Denninger wrote:
This does make sense - a lot of sense.
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
On Sat, May 30, 1998 at 12:26:31AM -0400, Jamie Scheinblum wrote:
Suggestion:
The initial ASN should be bundled with a /19 to create a "multi-home" package. Unbundled ASNs whould be unreasonably high to cover the administration of the initial ASNs of the world, and the cost associated with a /19.
No, it does not make a lot of sense. In fact, IMHO, this is a very, *very* bad idea.
Remember what we are trying to conserve here - not just ASNs, but IP Space too. Making unbundled ASNs "unreasonably high" would kill all the people who are being good little businesses and conserving IP space.
Uh, hold on a second.... I didn't say to make the first ASN "unreasonably" expensive (and I do believe $500 is unreasonable). However, with a REASONABLE first ASN fee (ie: $50 or thereabouts) bundling THAT with a /19 when you get your first PI allocation is even more reasonable. After all, the justification for the IP space encompasses that for the ASN, so the work has already been done, and the additional effort at that point should be literally a few keystrokes. My proposals to fix the issue with regards to getting a /19 if you're multihomed are also out there; has NANOG seen them? -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
Guys, I hate to bring business issues up in a technical forum, but y'all started it. There is a definite business case for portable /21's. First off, I understand the technical need to limit ASN's to /19's so I don't need lecture #101. However, those limits were set quite some time ago. When can we reduce them? Has technology stood still? The need is for service ISP's, as opposed to Internet Access Providers. We need portability too. At 01:34 PM 5/31/98 -0500, Karl Denninger wrote:
On Sun, May 31, 1998 at 12:30:46AM -0700, Patrick W. Gilmore wrote:
At 01:27 AM 5/30/98 -0500, Karl Denninger wrote:
This does make sense - a lot of sense.
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
On Sat, May 30, 1998 at 12:26:31AM -0400, Jamie Scheinblum wrote:
Suggestion:
The initial ASN should be bundled with a /19 to create a "multi-home" package. Unbundled ASNs whould be unreasonably high to cover the administration of the initial ASNs of the world, and the cost associated with a /19.
No, it does not make a lot of sense. In fact, IMHO, this is a very, *very* bad idea.
Remember what we are trying to conserve here - not just ASNs, but IP Space too. Making unbundled ASNs "unreasonably high" would kill all the people who are being good little businesses and conserving IP space.
Uh, hold on a second....
I didn't say to make the first ASN "unreasonably" expensive (and I do believe $500 is unreasonable).
However, with a REASONABLE first ASN fee (ie: $50 or thereabouts) bundling THAT with a /19 when you get your first PI allocation is even more reasonable.
After all, the justification for the IP space encompasses that for the ASN, so the work has already been done, and the additional effort at that point should be literally a few keystrokes.
My proposals to fix the issue with regards to getting a /19 if you're multihomed are also out there; has NANOG seen them?
-- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
___________________________________________________ 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/ ___________________________________________ SecureMail from MHSC.NET is coming soon!
On Sun, May 31, 1998 at 12:52:04PM -0700, Roeland M.J. Meyer wrote:
Guys, I hate to bring business issues up in a technical forum, but y'all started it.
There is a definite business case for portable /21's. First off, I understand the technical need to limit ASN's to /19's so I don't need lecture #101. However, those limits were set quite some time ago. When can we reduce them? Has technology stood still?
No, it has not.
The need is for service ISP's, as opposed to Internet Access Providers. We need portability too.
Tell me about it. The whole /19 thing started as a bad idea, and has propagated because other people picked up on it and said "yeah, ok" and then formulated policy around it - instead of whacking the first person with a wet noodle. There are some providers out there who think that there's no reason they should have to spend money on RAM and CPU in their core routers. There's a curious correlation between those folks, and the ones with the largest number of route announcements too. :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost
At 12:52 PM 5/31/98 -0700, Roeland M.J. Meyer wrote:
There is a definite business case for portable /21's. First off, I understand the technical need to limit ASN's to /19's so I don't need lecture #101. However, those limits were set quite some time ago. When can we reduce them? Has technology stood still?
You understand "the technical need to limit ASN's to /19's"? I don't, perhaps you could explain it to me. I have a whole bunch of multi-homed downstreams who have /21s or /20s - with their own ASNs. Should we just give them more space? Or are they "not allowed" to multi-home? What am I missing?
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" **************************************************************
At 02:16 AM 6/1/98 -0700, Patrick W. Gilmore wrote:
At 12:52 PM 5/31/98 -0700, Roeland M.J. Meyer wrote:
There is a definite business case for portable /21's. First off, I understand the technical need to limit ASN's to /19's so I don't need lecture #101. However, those limits were set quite some time ago. When can we reduce them? Has technology stood still?
You understand "the technical need to limit ASN's to /19's"? I don't, perhaps you could explain it to me.
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. Damn! Now you gotten *me* to send lecture #101, sheesh! |;-)
I have a whole bunch of multi-homed downstreams who have /21s or /20s - with their own ASNs. Should we just give them more space? Or are they "not allowed" to multi-home? What am I missing?
Read the current ARIN pages. Unless I read them wrong, an ASN now requires a /19 to go with it. Anything less will not be approved. Existing /20's and /21's are under legacy grand-fathering.
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" **************************************************************
___________________________________________________ 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/ ___________________________________________ SecureMail from MHSC.NET is coming soon!
Read the current ARIN pages. Unless I read them wrong, an ASN now requires a /19 to go with it. Anything less will not be approved. Existing /20's and /21's are under legacy grand-fathering.
There is no requirement to have a /19 in order to receive an ASN. Kim Hubbard ARIN
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" **************************************************************
___________________________________________________ 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/ ___________________________________________ SecureMail from MHSC.NET is coming soon!
Roeland M.J. Meyer writes...
At 02:16 AM 6/1/98 -0700, Patrick W. Gilmore wrote:
At 12:52 PM 5/31/98 -0700, Roeland M.J. Meyer wrote:
There is a definite business case for portable /21's. First off, I understand the technical need to limit ASN's to /19's so I don't need lecture #101. However, those limits were set quite some time ago. When can we reduce them? Has technology stood still?
You understand "the technical need to limit ASN's to /19's"? I don't, perhaps you could explain it to me.
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.
There are two basic problems: 1. The number of available ASNs is finite and usage is growing. 2. The number of route prefixes impacts on router performance and is growing rapidly. The greatest concern seems not to be #1 but instead #2. The idea of limiting prefixes being honored to /19 and shorter is one approach to limiting the number of prefixes. However, this tactic has the counterproductive effect of discouraging smaller (and more numerous) providers and businesses from being efficient in their usage of IP address space, for networks that need less space than a /19 allows. We can suggest that this /19 boundary be changed. Moving it to /18 would further reduce the number of prefixes, but create more demand on IP space. Moving it to /20 would decrease the demand on IP space, but increase the number of prefixes. What we need is a solution where we don't have to make tradeoffs between increases in the number of prefixes and increased waste of IP space. The prefixes glut comes from two different situations. One of them is the increasing number of autonomous, or multi-homed, networks. The other is the multitudes of un-aggregated and unaggregateable prefixes being announced in each AS. IPv6 may make it easier to eventually do all the aggregation that is needed, but it would NOT decrease the number of distinct autonomous networks that need to separately announce. If IPv6 allocates space in differing sizes (for example, UUNET may be given a /64 with 18446744073709551616 addresses, but MOM-AND-POP.NET maybe be given "only" a /80 with 281474976710656 addresses) we are still going to see network size bias and discrimination when it comes to filtering route prefixes. People will find (very clever) ways to use up their /80 so they can then ask for maybe a /64. If IPv6 allocates everyone the same exact network size (for example /64) no matter how big or small they are, it can end the bias and discrimination. We'll still have lots of routes, but at least in this case we could have just one route prefix per entity. Still, very large businesses could ask for multiple blocks or even large blocks for reasons of doing various strategies of network partitioning, and the problem of routes comes back since we'll either have varying sizes of prefixes (and the bias) or we'll have multiple prefixes (and the glut). While IPv6 needs to be considered, the immediate problem is still IPv4. One idea I had that could reduce the number of prefixes would be to make some limit on the number of prefixes per AS. This could be either a flat limit on the number of prefixes, or a partitioned limit on the number of prefixes per each size (same in each size). I like the latter because it does discourage keeping multitudes of small network pieces (which is probably why prefix filtering really got started in the first place). Unfortunately, access lists are not smart enough to count prefixes per AS to apply a limit, so some new code would have to be added to the BGP logic in the routers to do this. I would suggest the default limit be set at 2 prefixes per prefix size /17 through /24, with a total limit of 5 prefixes in this whole range, and no limit (for now) on prefixes of /16 or shorter. It may be necessary to exclude certain network block ranges from these counts. The best solution distributes the least information level for each autonomous network. Unfortunately, ASNs do not alone provide enough information so we still have prefixes. I wish there was a way out of that. I did develop an idea along those lines a couple years ago. But it is probably too late to do something like that in IPv6 now. -- Phil Howard | stop0550@lame4ads.org a7b7c8d2@spam1mer.org crash881@dumb9ads.com phil | stop0ads@no0where.net ads8suck@s8p4a2m4.org no1spam6@no9place.com at | stop0ads@dumb9ads.edu eat8this@spammer9.com stop3506@dumbads6.com ipal | w6x1y5z0@s3p8a7m1.com ads0suck@spam3mer.edu eat2this@lame9ads.org dot | blow4me8@spam1mer.com end2it58@lame9ads.com a1b8c1d3@no4place.net net | no5way49@dumbads9.org suck3it5@dumb8ads.net ads2suck@no6place.org
Roeland M.J. Meyer writes...
At 02:16 AM 6/1/98 -0700, Patrick W. Gilmore wrote:
One idea I had that could reduce the number of prefixes would be to make some limit on the number of prefixes per AS. This could be either a flat limit on the number of prefixes, or a partitioned limit on the number of prefixes per each size (same in each size). I like the latter because it does discourage keeping multitudes of small network pieces (which is probably why prefix filtering really got started in the first place). Unfortunately, access lists are not smart enough to count prefixes per AS to apply a limit, so some new code would have to be added to the BGP logic in the routers to do this. I would suggest the default limit be set at 2 prefixes per prefix size /17 through /24, with a total limit of 5 prefixes in this whole range, and no limit (for now) on prefixes of /16 or shorter. It may be necessary to exclude certain network block ranges from these counts.
This would have one effect. ISP's would require any and all customers who have their own space to run BGP and use their own AS, therefore just sticking a variety of different labels on routes that were previously under the ISP's announcements. This point isn't even taking into account how absolutely real it is for a medium size ISP to have 3 /17s or 3 /18s or 3 /19s or 6 prefixes from /17 to /24. Given that this would seriously impact the larger NSP's (how many /24's do you think Sprint, MCI, and UUNet) announce for non-BGP customers, how realistic do you view this proposal? /* Beginning Rant */ Not to sound bitter, but the vast majority of the contributers to this list have gone from using engineering practices for the good of the net to using engineering practices to make it work, given the goals and limitations of corporate policy. Any other approach can't get the dollars behind it and compete with the corporate direction of "well if other providers are willing to limit their potential customer revenues by making this policy, we can just buy RSP-4's and get the customers they lose". Our ideas and suggestions need to be both good for the net, and not vulnerable to someone out there flying in the face of it to make a buck. Sprint's filtering policies are one of the few filtering plans that was successfully imposed upon the net that actually stuck (read, significantly impacted a majority of us in dealing with inter-provider announcements). The only way they did make it stick and not cost them large amounts of revenue was to make exceptions for their own customers thereby removing the "good of the net" result and making it "good for Sprint". Cabal-like engineering mandates may be damn good for the routers, but the dollars behind the routers are speaking much louder with each passing day. It is not only naive, but irresponsible to count on the technical "good of the network" arguments to continue to dismiss without question or compromise, business concerns, especially when such proposed and/or implimented methods cause complaints of hardship from paying customers which assuredly reach those who's chief concern is the satisfaction of the stockholders. /* End of Rant */ I suppose they'll be asking for my Techno-Socialist badge to be turned in by morning. --------------------------------------------------------------------------- ** Andrew W. Smith ** awsmith@neosoft.com ** Chief Network Engineer ** ** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT ** ** "Opportunities multiply as they are seized" - Sun Tzu ** ---------------------------------------------------------------------------
Andrew Smith writes...
This would have one effect. ISP's would require any and all customers who have their own space to run BGP and use their own AS, therefore just sticking a variety of different labels on routes that were previously under the ISP's announcements.
Unless the customer has a larger network, /19 or shorter, they will face the same problem with prefix filters in certain networks like Sprint. Sure, this can be a problem, but the goal is to aggregate prefixes. If this won't encourage it, then it's a bad plan. But the goal still remains.
This point isn't even taking into account how absolutely real it is for a medium size ISP to have 3 /17s or 3 /18s or 3 /19s or 6 prefixes from /17 to /24.
They are taking up 15 prefixes in my route table, when they could aggregate their space by renumbering into a single /15 or /14 and take only one? If the high number of prefixes out there is NOT a problem, then say so. If that is the case, then Sprint has no justification for filtering the routes by prefix size.
Given that this would seriously impact the larger NSP's (how many /24's do you think Sprint, MCI, and UUNet) announce for non-BGP customers, how realistic do you view this proposal?
Us smaller ISPs are being required to constantly renumber our space just to get more space. So tell me what the boundary is where an ISP can grow past where they no longer are required to renumber space? We see "size bias" from Sprint in their filtering. Are we also seeing "size bias" in how ISPs are treated with respect to renumbering policies?
/* Beginning Rant */
Not to sound bitter, but the vast majority of the contributers to this list have gone from using engineering practices for the good of the net to using engineering practices to make it work, given the goals and limitations of corporate policy. Any other approach can't get the dollars behind it and compete with the corporate direction of "well if other providers are willing to limit their potential customer revenues by making this policy, we can just buy RSP-4's and get the customers they lose".
As it stands now, small ISPs are the ones with the potential to lose customers because of the existing "size bias" with respect to filters against long prefixes.
Our ideas and suggestions need to be both good for the net, and not vulnerable to someone out there flying in the face of it to make a buck. Sprint's filtering policies are one of the few filtering plans that was successfully imposed upon the net that actually stuck (read, significantly impacted a majority of us in dealing with inter-provider announcements). The only way they did make it stick and not cost them large amounts of revenue was to make exceptions for their own customers thereby removing the "good of the net" result and making it "good for Sprint".
You're being vague here. In on breath you are saying Sprint's policy is good, and then saying it is not good for the net, but only good for Sprint. Well, I can see how it is good for Sprint. With filters they can go cheap on router memory and CPU speed and save a few bucks, possibly charging less for their customers, and certainly making more profit. This, from a business standpoint, is certainly good for Sprint in the short term. But a small web provider business that was smart enough to implement their web services using shared IP addresses, instead of putting each web site on its own IP address, can do it in a /26 instead of a /19, but gets shafted by Sprint. Maybe you are suggesting that they hook up to Sprint and become and expection? Maybe I suggest that they blackhole all of Sprint instead.
Cabal-like engineering mandates may be damn good for the routers, but the dollars behind the routers are speaking much louder with each passing day. It is not only naive, but irresponsible to count on the technical "good of the network" arguments to continue to dismiss without question or compromise, business concerns, especially when such proposed and/or implimented methods cause complaints of hardship from paying customers which assuredly reach those who's chief concern is the satisfaction of the stockholders.
I agree there are concerns for router efficiency. But some other solution is needed aside from requiring everyone to get a /19 (which once everyone does, Sprint will raise the bar to /18 or /17 or some such level). There needs to be a solution where the small (whether because their business is small or because their engineering is wise) are treated equally to the large. I did say that at some level the number of prefixes might no longer need to be counted. Would Sprint be willing to allow the one largest prefix in the /29 to /20 range, per each AS, through, if the software provided a feature to automatically pick it out from the announcements for each AS, and just let all /19 and shorter through as they do now? That would increase the number of prefixes they have to deal with by some amount, while encouraging the smaller ISPs to keep their space well aggregated. It would still allow the large ISPs to flood the route space with excess numbers of prefixes, it which seems they want to be able to do while not allowing the smaller ones to do so. By all means, my idea is not ideal. But the existing situation is not, either, unless you are willing to give each of your multi-home customers a /19 block, whether then need that many addresses or not. Got any better ideas? I'd really like to see one that is better than the choices we have now. -- Phil Howard | stop3it9@s3p7a1m8.com stop2ads@no6where.com no7spam4@no5where.net phil | stop7it1@noplace7.com ads3suck@no4place.org stop9630@no7place.org at | stop0ads@nowhere4.com stop6137@s2p9a0m5.com no16ads2@anywhere.edu ipal | die6spam@anywhere.com ads8suck@dumb3ads.net no0way65@anyplace.com dot | stop5it7@s9p5a5m6.com no6spam3@spammer0.edu die2spam@spam5mer.com net | end1it62@no6where.edu end4it88@no7place.edu stop6609@no8where.net
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" **************************************************************
At 01:34 PM 5/31/98 -0500, Karl Denninger wrote:
Uh, hold on a second....
I didn't say to make the first ASN "unreasonably" expensive (and I do believe $500 is unreasonable).
No, you just said "This does make sense - a lot of sense." when Jamie Scheinblum suggested that "unbundled" ASNs be made unreasonably high.
However, with a REASONABLE first ASN fee (ie: $50 or thereabouts) bundling THAT with a /19 when you get your first PI allocation is even more reasonable.
While I agree that $500 *might* be too high, I honestly do not think something on the order of $200 or $250 would be too high, especially as a "one time" fee with the $30 recurring charge.
After all, the justification for the IP space encompasses that for the ASN, so the work has already been done, and the additional effort at that point should be literally a few keystrokes.
Good point.
My proposals to fix the issue with regards to getting a /19 if you're multihomed are also out there; has NANOG seen them?
I have not. But I haven't been following this as closely as I probably should have.
Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin
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" **************************************************************
participants (7)
-
Andrew Smith -
Jamie Scheinblum -
Karl Denninger -
Kim Hubbard -
Patrick W. Gilmore -
Phil Howard -
Roeland M.J. Meyer