North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Policy Statement on Address Space Allocations
- From: Forrest W. Christian
- Date: Fri Jan 26 18:46:38 1996
(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.
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
> *> 22.214.171.124 126.96.36.199 0 4000 ?
> *> 188.8.131.52 184.108.40.206 0 4000 ?
> *> 220.127.116.11 18.104.22.168 0 4000 ?
> *> 22.214.171.124/19 126.96.36.199 0 4000 ?
> *> 188.8.131.52 184.108.40.206 0 4000 ?
> *> 220.127.116.11 18.104.22.168 0 4000 ?
> *> 22.214.171.124 126.96.36.199 0 4000 ?
> *> 188.8.131.52/19 184.108.40.206 0 4000 ?
> *> 220.127.116.11/19 18.104.22.168 0 4000 i
> *> 22.214.171.124/23 126.96.36.199 0 4000 ?
> *> 188.8.131.52 184.108.40.206 0 4000 ?
> *> 220.127.116.11 18.104.22.168 0 4000 ?
> *> 22.214.171.124 126.96.36.199 0 4000 ?
> *> 188.8.131.52 184.108.40.206 0 4000 ?
> *> 220.127.116.11 18.104.22.168 0 4000 ?
> *> 22.214.171.124 126.96.36.199 0 4000 ?
> *> 188.8.131.52/19 184.108.40.206 0 4000 ?
> *> 220.127.116.11/21 18.104.22.168 0 4000 ?
> *> 22.214.171.124/18 126.96.36.199 0 4000 ?
> *> 188.8.131.52/20 184.108.40.206 0 4000 ?
> *> 220.127.116.11/19 18.104.22.168 0 4000 ?
> *> 22.214.171.124/23 126.96.36.199 0 4000 ?
> *> 188.8.131.52 184.108.40.206 0 4000 ?
> *> 220.127.116.11 18.104.22.168 0 4000 ?
> *> 22.214.171.124 126.96.36.199 0 4000 ?
> *> 188.8.131.52/16 184.108.40.206 0 4000 i
> *> 220.127.116.11 18.104.22.168 0 4000 ?
> *> 22.214.171.124 126.96.36.199 0 4000 ?
> *> 188.8.131.52 184.108.40.206 0 4000 ?
> *> 220.127.116.11/18 18.104.22.168 0 4000 i
> *> 22.214.171.124 126.96.36.199 0 4000 ?