Policy Statement on Address Space Allocations

Daniel Karrenberg <Daniel.Karrenberg at ripe.net> wrote:
> 
>   > "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.

Neither do I.
 
>   > 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.

OK, point taken. But AFAIK RIPE *still* works against this goal by giving
only one window. Case in point: Our current window is /19, and all our
announcements are maximally aggregated. Jo Customer comes along
to me and says 'I want to go multihomed with you as a second provider,
currently I have 8 class C's but they are all spread about the
place'. Me 'You need to renumber then esp. as your class C's are
within your current providers aggregate announcments (even though
they are old, and thus technically PI' (there, that's me doing my
bit for aggregation). Them: 'OK, give us a /21 to renumber into, 
you are a local-IR and we aren't'. Currently I have 2 choices as
far as I can make out, give them a bit of my /19, break up my
nice aggregate and ensure loads of extra announcements (and that
probably none of them get routed by anyone applying prefix based
filtering), or give them a new /19 all of their own (you've
said it, that's the minimum size allocation) which actually
solves their problem and mine, but this isn't an option
currently available because currently it's one window per local-IR.
So they have to go and become a local IR.

> This is why pure prefix length filtering is the wrong soloution.
> It just favours the big providers. 

Yup, I'd agree with us. And I hope Sprint have had a long chat with
their lawyers over there as some of the more litigious smaller US
providers are busy thumbing through the anti-trust laws, apparently.

> 
...
> 
> This bartering does not solve the general problem and does not
> claim to. It is just part of the effort to keep things working.

Yup.

Alex Bligh
Xara Networks.