Re: Policy Statement on Address Space Allocations
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
If you insist on prefix-length filtering I have proposed a soloution for future address space allocated via the RIPE NCC several times:
- set your inbound prefix length filter to /19.
- The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8.
- The RIPE NCC will continue to work with the providers to maximise aggregation. Our goal is a maximum of 1024 routes per /8 visible at major exchange points. Incidentally this is the same goal that you seem to have.
You are not distinguishing (initial) allocation from announcement. Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS, and thus, for instance that none of the allocation is for PI space, or for allocation to customers who aren't local-IRs but have their own AS etc. etc. You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this? Alex Bligh Xara Networks PS: Here's Sprint's sister company's current announcement of routes *originating* in its AS as I see them - I do hope Sprint takes the honest path if it does refuse to carry short announcements and not route all bar 4 of these nets, as well as a similar long list from AS1239 :-) I'm not convinced Sprint has the moral highground here.... Network Next Hop Metric LocPrf Weight Path *> 160.214.0.0 194.68.130.50 0 4000 ? *> 163.164.0.0 194.68.130.50 0 4000 ? *> 194.41.63.0 194.68.130.50 0 4000 ? *> 194.106.0.0/19 194.68.130.50 0 4000 ? *> 194.106.32.0 194.68.130.50 0 4000 ? *> 194.106.33.0 194.68.130.50 0 4000 ? *> 194.106.34.0 194.68.130.50 0 4000 ? *> 194.126.64.0/19 194.68.130.50 0 4000 ? *> 194.133.0.0/19 194.68.130.50 0 4000 i *> 194.133.4.0/23 194.68.130.50 0 4000 ? *> 194.133.6.0 194.68.130.50 0 4000 ? *> 194.133.7.0 194.68.130.50 0 4000 ? *> 194.133.8.0 194.68.130.50 0 4000 ? *> 194.133.15.0 194.68.130.50 0 4000 ? *> 194.133.24.0 194.68.130.50 0 4000 ? *> 194.133.28.0 194.68.130.50 0 4000 ? *> 194.140.128.0/19 194.68.130.50 0 4000 ? *> 194.140.224.0/21 194.68.130.50 0 4000 ? *> 194.149.192.0/18 194.68.130.50 0 4000 ? *> 194.158.0.0/20 194.68.130.50 0 4000 ? *> 194.176.96.0/19 194.68.130.50 0 4000 ? *> 194.204.96.0/23 194.68.130.50 0 4000 ? *> 196.27.0.0 194.68.130.50 0 4000 ? *> 196.27.1.0 194.68.130.50 0 4000 ? *> 198.169.26.0 194.68.130.50 0 4000 ? *> 204.59.0.0/16 194.68.130.50 0 4000 i *> 204.83.37.0 194.68.130.50 0 4000 ? *> 204.83.237.0 194.68.130.50 0 4000 ? *> 204.83.254.0 194.68.130.50 0 4000 ? *> 206.49.64.0/18 194.68.130.50 0 4000 i *> 206.49.65.0 194.68.130.50 0 4000 ?
(If this isn't appropriate for nanog, would someone drop me a note in private? All other CC's deleted). I'll poke my nose in here again.... If you convince the registries to allocate no longer prefix than an /18 or a mix of lengths up to say /19 or /20 (such that no more than 1000ish are allocated) to ISP's or multihomed companies, and then require that the announcement must match the allocated block, you can guarantee that the routing table will not exceed the 1024 per /8. Then, some of you will ask how to enforce this. Once every so often, you dump the BGP routing tables from strategic routers. If you see any non-matching prefixes, you send an email to the network coordinator for the allocated block giving them a set amount of time to clean it up. Any routes which are not cleaned up by the deadline are added to a filter list which could be carried on routers. This method would have (at least) the following advantages (or disadvantages, from your particular viewpoint): 1) You could reasonably assure that the number of prefixes in an /8 would match what was allocated. 2) Because of 1, if you get the registries to set their allocation policies such that no more than 1024 (or the target number) blocks are allocated per /8, you can guarantee that the number of routes in an /8 is not too far out of wack with the target. 3) You can give those people moving providers a grace period to renumber, say 30 days. Essentially, the time given to clean up the routing tables. This would be a side effect of the "you have 30 days to fix the routing tables or else". 4) You eliminate the wasted space of addresses with prefixes longer than /18 being allocated. The only problem this leaves is how to decide who gets an /18... BTW, I'm willing to write (for free) the tool to compare the routing table to a registry, assuming someone can provide me with a copy or a source for the IP registry files, or a subset thereof. -forrest On Fri, 26 Jan 1996, Alex.Bligh wrote:
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
If you insist on prefix-length filtering I have proposed a soloution for future address space allocated via the RIPE NCC several times:
- set your inbound prefix length filter to /19.
- The RIPE NCC will *guarantee* that we will not make more than 1024 non-aggregateable allocations from each /8.
- The RIPE NCC will continue to work with the providers to maximise aggregation. Our goal is a maximum of 1024 routes per /8 visible at major exchange points. Incidentally this is the same goal that you seem to have.
You are not distinguishing (initial) allocation from announcement.
Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS, and thus, for instance that none of the allocation is for PI space, or for allocation to customers who aren't local-IRs but have their own AS etc. etc. You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this?
Alex Bligh Xara Networks
PS: Here's Sprint's sister company's current announcement of routes *originating* in its AS as I see them - I do hope Sprint takes the honest path if it does refuse to carry short announcements and not route all bar 4 of these nets, as well as a similar long list from AS1239 :-) I'm not convinced Sprint has the moral highground here....
Network Next Hop Metric LocPrf Weight Path *> 160.214.0.0 194.68.130.50 0 4000 ? *> 163.164.0.0 194.68.130.50 0 4000 ? *> 194.41.63.0 194.68.130.50 0 4000 ? *> 194.106.0.0/19 194.68.130.50 0 4000 ? *> 194.106.32.0 194.68.130.50 0 4000 ? *> 194.106.33.0 194.68.130.50 0 4000 ? *> 194.106.34.0 194.68.130.50 0 4000 ? *> 194.126.64.0/19 194.68.130.50 0 4000 ? *> 194.133.0.0/19 194.68.130.50 0 4000 i *> 194.133.4.0/23 194.68.130.50 0 4000 ? *> 194.133.6.0 194.68.130.50 0 4000 ? *> 194.133.7.0 194.68.130.50 0 4000 ? *> 194.133.8.0 194.68.130.50 0 4000 ? *> 194.133.15.0 194.68.130.50 0 4000 ? *> 194.133.24.0 194.68.130.50 0 4000 ? *> 194.133.28.0 194.68.130.50 0 4000 ? *> 194.140.128.0/19 194.68.130.50 0 4000 ? *> 194.140.224.0/21 194.68.130.50 0 4000 ? *> 194.149.192.0/18 194.68.130.50 0 4000 ? *> 194.158.0.0/20 194.68.130.50 0 4000 ? *> 194.176.96.0/19 194.68.130.50 0 4000 ? *> 194.204.96.0/23 194.68.130.50 0 4000 ? *> 196.27.0.0 194.68.130.50 0 4000 ? *> 196.27.1.0 194.68.130.50 0 4000 ? *> 198.169.26.0 194.68.130.50 0 4000 ? *> 204.59.0.0/16 194.68.130.50 0 4000 i *> 204.83.37.0 194.68.130.50 0 4000 ? *> 204.83.237.0 194.68.130.50 0 4000 ? *> 204.83.254.0 194.68.130.50 0 4000 ? *> 206.49.64.0/18 194.68.130.50 0 4000 i *> 206.49.65.0 194.68.130.50 0 4000 ?
Forrest,
This method would have (at least) the following advantages (or disadvantages, from your particular viewpoint):
1) You could reasonably assure that the number of prefixes in an /8 would match what was allocated.
2) Because of 1, if you get the registries to set their allocation policies such that no more than 1024 (or the target number) blocks are allocated per /8, you can guarantee that the number of routes in an /8 is not too far out of wack with the target.
3) You can give those people moving providers a grace period to renumber, say 30 days. Essentially, the time given to clean up the routing tables. This would be a side effect of the "you have 30 days to fix the routing tables or else".
4) You eliminate the wasted space of addresses with prefixes longer than /18 being allocated.
The only problem this leaves is how to decide who gets an /18...
That is a *very good question*. Different answers to this question have *quite different* implications on the address space utilization. Yakov.
On Fri, 26 Jan 1996, Yakov Rekhter wrote:
Forrest,
The only problem this leaves is how to decide who gets an /18...
That is a *very good question*. Different answers to this question have *quite different* implications on the address space utilization.
My personal opinion is that you err on the side of giving someone an /18 that doesn't need one, However you DO need to be careful about assigning the space. The general qualifications I would imagine are: 1) ISP's assigning (non-portable?) address space to non-dialup customers, on a fairly regular basis. 2) Large-ish companies which of themselves would need the /18. 3) Anyone who is multi-homed on a "permanent" basis. (Probably mostly covered by 1&2) -forrest
"Alex.Bligh" <amb@Xara.NET> writes:
You are not distinguishing (initial) allocation from announcement.
Correct. This is because it is *only* the allocation that a regional registry has *control* over. After that we can only have *influence*.
Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS,
I wouldn't call that worthless exactly, because the method has shown some successes.
and thus, for instance that none of the allocation is for PI space
I do not care about PI space. Those wanting it have had ample warning.
or for allocation to customers who aren't local-IRs but have their own AS etc. etc.
There you are! Cases of genuine need for a seperate announcement (multihomed) are not covered by the guarantee. But my expectation is that their number can be offset by bigger aggregates. Note that the number of routes *currently* announced under 193/8 and 194/8, which have some room for improvement, is quite low already. Actually they are both within the theoretical limit of a /18 filter which is 2047 routes.
You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this?
I fully agree that this is a problem. I believe that the only real solution to this is to reduce *unneeded* announcements as much as possible. This needs a routing registry and tools. This is why pure prefix length filtering is the wrong soloution. It just favours the big providers. The argument I am having with Sean is just part of this whole area: He says: "Change your allocation policy to match my routing policy." IANA says: "Registries shall not make allocations/assignments based on (individual) ISP's routing policies." (With which I fully agree) I say: "Change your routing policy very slightly such that it remains compatible with my allocation policy." This bartering does not solve the general problem and does not claim to. It is just part of the effort to keep things working. Daniel
Daniel Karrenberg <Daniel.Karrenberg@ripe.net> wrote:
"Alex.Bligh" <amb@Xara.NET> writes:
You are not distinguishing (initial) allocation from announcement.
Correct. This is because it is *only* the allocation that a regional registry has *control* over. After that we can only have *influence*.
Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS,
I wouldn't call that worthless exactly, because the method has shown some successes.
and thus, for instance that none of the allocation is for PI space
I do not care about PI space. Those wanting it have had ample warning.
Neither do I.
or for allocation to customers who aren't local-IRs but have their own AS etc. etc.
There you are! Cases of genuine need for a seperate announcement (multihomed) are not covered by the guarantee. But my expectation is that their number can be offset by bigger aggregates. Note that the number of routes *currently* announced under 193/8 and 194/8, which have some room for improvement, is quite low already. Actually they are both within the theoretical limit of a /18 filter which is 2047 routes.
You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this?
I fully agree that this is a problem. I believe that the only real solution to this is to reduce *unneeded* announcements as much as possible. This needs a routing registry and tools.
OK, point taken. But AFAIK RIPE *still* works against this goal by giving only one window. Case in point: Our current window is /19, and all our announcements are maximally aggregated. Jo Customer comes along to me and says 'I want to go multihomed with you as a second provider, currently I have 8 class C's but they are all spread about the place'. Me 'You need to renumber then esp. as your class C's are within your current providers aggregate announcments (even though they are old, and thus technically PI' (there, that's me doing my bit for aggregation). Them: 'OK, give us a /21 to renumber into, you are a local-IR and we aren't'. Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR.
This is why pure prefix length filtering is the wrong soloution. It just favours the big providers.
Yup, I'd agree with us. And I hope Sprint have had a long chat with their lawyers over there as some of the more litigious smaller US providers are busy thumbing through the anti-trust laws, apparently.
...
This bartering does not solve the general problem and does not claim to. It is just part of the effort to keep things working.
Yup. Alex Bligh Xara Networks.
to me and says 'I want to go multihomed with you as a second provider, currently I have 8 class C's but they are all spread about the place'. Me 'You need to renumber then esp. as your class C's are within your current providers aggregate announcments (even though they are old, and thus technically PI' (there, that's me doing my bit for aggregation). Them: 'OK, give us a /21 to renumber into, you are a local-IR and we aren't'. Currently I have 2 choices as far as I can make out, give them a bit of my /19, break up my nice aggregate and ensure loads of extra announcements (and that probably none of them get routed by anyone applying prefix based filtering), or give them a new /19 all of their own (you've said it, that's the minimum size allocation) which actually solves their problem and mine, but this isn't an option currently available because currently it's one window per local-IR. So they have to go and become a local IR.
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Iljitsch van Beijnum <iljitsch@unix1.bart.nl> wrote:
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers? Alex Bligh Xara Networks
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well.
Well that's their policy, so it's their problem. As an ISP selling "global Internet connectivity" I may choose to take that policy into consideration, but I'm sure most people don't give a damn. (This is starting to get more and more like FidoNet...)
What hope for a customer with those IP numbers?
The anti-trust laws. ;-) Iljitsch
On Mon, 29 Jan 1996, Alex.Bligh wrote:
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers?
They all pay somebody (NSP X) for the following service. NSP X announces an aggregate route, ???/8 or whatever, which Sprint and others *WILL* listen to. Then, NSP X reroutes traffic to all those different customers within it's own network. If NSP X needs to route through another NSP for some reason, then NSP X uses an IP tunnel to encapsulate the swampy address. Of course, this may cost more than the swamp customers want to pay, or the swamp customers may not be able to agree enough to create a globally routable aggregate. In that case, they don't get routed. Hopefully they can be convinced to renumber and release the swamp addresses, thus filling in the swamp and allowing somebody to build a nice parking lot, mall and attached apartment buildings. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael@memra.com
Introduction: ------------- There have been several suggestions on the nanog list recently about ways to clean up the IP address "swamps" created by prior, piecemeal allocations of class C addresses. I understand the PIER Working Group of the IETF, with the approval of the IANA and Internic, are currently surveying those swamps to provide data for evaluating proposed solutions. Before making addtional proposals one might then do well to ask, "What criteria should a 'good' solution meet?" Here's my list: - Impose few administrative costs on end users. Approaches involving renumbering or installing IP tunnels won't meet this criterion until much better tools are available. - Depend only on voluntary participation by Internet providers. - Gain for participating providers smaller route tables. - Assure that no customer of a provider is unduly harmed by the provider's participation. Can a solution be found that includes all these criteria? Perhaps not, but here's a "straw" proposal nonetheless. Proposal: --------- Participating providers divide a swamp into sections. For example, four providers could divide 192/8 into 192.0/10, 192.64/10, 192.128/10, and 192.196/10. Each provider continues to announce its customer /24 routes, but in addition each announces to the others one of the four /10 routes. For the /10 route which it announces, each provider accepts and keeps all the /24 routes it hears. For the other three, it keeps only the /10 route and filters out any /24 routes it hears. The resulting routing might be inefficient: provider A might deliver packets to provider B that are eventually destined for a customer of provider C. But packets do continue to reach their ultimate destinations. Providers get smaller route tables, while customers remain blissfully unaware (and thus continue to pay for service ;-). Note that four is not a magic number: any two providers could bilaterally enter into an agreement of this type and get reduced route table sizes. Personal Note: -------------- As an observer on the sidelines of nanog activity, I certainly lack the experience of the "older, wiser heads" who operate the major providers' backbone networks. Those with that experience, and the knowledge accrued therefrom, may well find gaping holes in this straw proposal. I look forward to their criticism, either in traffic on the list, in private email, or in person at the upcoming San Diego meeting. -- Sean Shapira sds@jazzie.com +1 206 443 2028 <a href="http://www.jazzie.com/sds/">Sean's Home Page</a> Serving the Net since 1990.
On Mon, 29 Jan 1996, Alex.Bligh wrote:
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers?
They all pay somebody (NSP X) for the following service.
NSP X announces an aggregate route, ???/8 or whatever, which Sprint and others *WILL* listen to. Then, NSP X reroutes traffic to all those different customers within it's own network. If NSP X needs to route through another NSP for some reason, then NSP X uses an IP tunnel to encapsulate the swampy address.
This is not beautiful but would work but...
Of course, this may cost more than the swamp customers want to pay, or the swamp customers may not be able to agree enough to create a globally routable aggregate. In that case, they don't get routed. Hopefully they can be convinced to renumber and release the swamp addresses, thus filling in the swamp and allowing somebody to build a nice parking lot, mall and attached apartment buildings.
I obviously didn't quote enough at the top of the message. The point was tht the potential swamp user wants PI addresses so he can get a more resilient connection and go multihomed, which was the very reason why they were thinking about the swamp at all (rather than renumbering into my easilly routable PA space). Your solution is fine for obstinate people who don't want to renumber, but the guys I'm concerned with have a good reason for a short announcement (i.e. they want more resilience). Now I suppose 2 NSPs could announce ???/8 and aggregate those, and reroute them, however they would have to be the same 2 NSPs. Also we're back to the geographic issue on this one, in that its quite likely that the tunnel of which you talk would go back from mainland Europe, Stateside, and back to me in the UK, i.e. instead of one transatlantic hop you get 3. I'd love to hear any solution where they can renumber *within existing rules* (remember they aren't a local-IR and can't justify a /19), use AS based announcement (they have a very good reason for doing this), and get routed. Alex Bligh Xara Networks
In message <199601291642.QAA09648@diamond.xara.net>, "Alex.Bligh" writes:
Iljitsch van Beijnum <iljitsch@unix1.bart.nl> wrote:
No they don't. You can ask the RIPE NCC for special PI space to assign to this customer. It seems they have a "chemical waste dump" to satisfy this kind of requests from.
Ah. That will be the "chemical waste dump" that Daniel K said he didn't care about whether it got routed or not (no offence Daniel - neither do I), and is all but unaggregatable so presumably Sprintlink et al. won't want to waste their CPUs routing it as well. What hope for a customer with those IP numbers?
Alex Bligh Xara Networks
Alex, Here's my suggestion. If you put that multi-homed customer in a larger aggregate (have them pick one of the providers and allocate from their address space) all of the providers must then announce the more specific. Some providers will block the longer prefix. The longer prefix will be preferred and traffic will avoid going through those providers that block it. This might cause longer or suboptimal routing for the longer prefix. Providers everywhere will have either the shorter prefix or both, so full connectivity would exist. If the multi-homing is sufficiently localized within the topology (for example, multiple providers in the same region or country) there might be a chance to draw an aggregation boundary around the whole thing and block the longer prefix outside of that locality and avoid the possibility of suboptimal routing due to long prefix filtering. Curtis
......... Alex.Bligh is rumored to have said: ] > No they don't. You can ask the RIPE NCC for special PI space to assign to ] > this customer. It seems they have a "chemical waste dump" to satisfy ] > this kind of requests from. ] Ah. That will be the "chemical waste dump" that Daniel K said ] he didn't care about whether it got routed or not (no offence ] Daniel - neither do I), and is all but unaggregatable so presumably ] Sprintlink et al. won't want to waste their CPUs routing it as well. ] What hope for a customer with those IP numbers? Learn how to renumber. It really is possible, you know. -alan
participants (9)
-
Alan Hannan -
Alex.Bligh -
Curtis Villamizar -
Daniel Karrenberg -
Forrest W. Christian -
Iljitsch van Beijnum -
Michael Dillon -
sds＠jazzie.com -
Yakov Rekhter