Policy Statement on Address Space Allocations

Mailman List Mirror (Read Only)
1

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

2

(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

3

"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