[address-policy-wg] 80% rule, based on feedback from the NCC RS department

On 26/02/2010 14:28, Gert Doering wrote:
> Now, "just changing the text according to what the WG chair thinks" would 
> not be the right thing - so what I think is the way forward now is to 
> get feedback from *you*, and if there is clear guidance from the working 
> group on resolving this ambiguity, we run a formal proposal to change the 
> wording of the document in one way or the other.
> 
> (Please don't get into sidetrack discussions on whether "80%" or "IPv4"
> is useful, but focus on this specific question.)

(tl;dr contingent: you can safely scroll to the exec summary at the bottom).

Rather than look at the immediate issue of which 80% rule trumps which, it
may be instructive to be slightly naughty and examine how the allocation
top-up mechanism works in practice.

>From what I remember (and I'm open to correction here), RIPE currently uses
interpretation #1.  I.e. all allocations must be at least 80% full before
the LIR is entitled to request more address space.  The net effect of this
policy is that where it's applied, the overall LIR utilisation will have a
lower bound of 80%, but will generally be higher than 80% overall.  If we
move to interpretation #2, we're lowering the bound to exactly 80%.

There are 6145 LIRs with ipv4 allocations defined in the following file:

ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt

If you'll excuse me for being sufficiently rude to post code, the top 50
LIRs have been allocated 236595200 ipv4 addresses (about 14 /8s) out of a
total allocation space of 474883072 allocated addresses (about 28 /8s).  So
that's a little less than 0.8% of the LIRs holding 50% of the address space.

For the purposes of this argument, I am ignoring the fact that most of the
larger service providers around Europe operate multiple LIRs, so the number
of addresses allocated to the largest 50 ipv4 address space holders in
Europe will probably well exceed 50%.

Now, these LIRs are entitled to request more address space when all their
allocations are 80% utilised.  Taking the top 50 LIRs, this means that
under the current utilisation policy, there is fully legitimate slack space
of 47319040 addresses, or almost 3 x /8s.

Which brings us back to the 80% policy.  I have two observations about it:

1. changing the policy to interpretation #2 will probably increase the
slack space by a small percentage, and taking only the top 50 LIRs into
account, this will work out to be a large number of addresses.

2. the slack ipv4 address space allocations held by the large LIRs already
represents a very large amount of address space indeed.

I contend that there is a legitimate argument to say that when the RIPE NCC
runs out of virgin IANA ipv4 space to allocate, the slack space held by the
tiny number of larger LIRs will effectively be allocated to them to the
very significant disadvantage of the much larger number of smaller LIRs.

Put another way, the 80% rule is fine for smaller LIRs, but is very biassed
in favour of larger LIRs.

If we're thinking about looking at how the 80% rule is applied, it may be
appropriate to take the opportunity to creating either a minimum
utilisation curve which starts out at 80% and increases monotonically
towards something significantly larger, or else a step / gradient system
which starts out at 80% for the first /x chunk of address space, 85% for
the next /y%, and so forth.

Nick
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: summarise-allocs.pl
URL: </ripe/mail/archives/address-policy-wg/attachments/20100301/8bb6cc49/attachment.pl>