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.)
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
(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. 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