Policy Statement on Address Space Allocations

Sat Jan 27 09:34:51 UTC 1996

  > "Alex.Bligh" <amb at 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