(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 ?