Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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.

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




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.