[ppml] Policy Proposals 2007-18 and -23
briand at ca.afilias.info
briand at ca.afilias.info
Thu Oct 18 12:38:38 EDT 2007
> Here is the jist of the modification to the proposal, which is basically
> clock-based (run-rate based):
Commenting on my own proposal, and clarifying the intent and details...
I neglected the existence of remaining unused portions of /8's within
the RIRs.
As such, there would need to be details modified about triggering events
and calculations...
> Immediately prior to the assignments for N=1, have a policy which will be
> triggered by a current consensus estimate among the RIRs that the
> *slowest* RIR run rate will use up one /8 before IANA Address Depletion,
> the remaining space is divided based on the projected usage between that
> time and IAD.
In order to avoid having two slow-use RIRs being in a race condition, where
one gets a /8 that will bring it *close* to IAD but not past it, and the
other then causing the triggering of the policy, it would need to be
changed slightly:
The trigger event would be an RIR requesting a /8, where *that* RIR would,
based on projected use, not be able to use up two /8's before IAD.
In other words, that IAD would occur before the RIR used up that /8 and
one other /8. (The second /8 would be one of the five /8's given to
the RIRs as a result of 2007-23.)
Since the *first* instance of an RIR meeting this condition would trigger
the rest of this proposal, we can be sure that no race condition will
result (other than very slight variations in usage during the very final
period, which are expected to fit within the rounding error of /12.)
> (For absolute fairness, allow any RIR to hit the "panic button", with the
> caveat that if the slowest-growing RIR hits the panic button, that RIR
> would
> only get their one last /8.)
>
> One /8 is subtracted from this value, to be given out per -23.
> The remainder is allocated in as aggregatable a fashion, but with a
> granularity of /12, and given to the RIRs based on projected use.
The above would be modified according to the following:
... after subtracting the current remaining unallocated space from each
RIR's current /8.
> This distribution will leave one /8 per RIR, which will trigger 2007-23.
>
> And, combined with 2007-23, this policy will result in near simultaneous
> RIR exhaustion dates for all RIRs.
>
> For example (and example only):
> Imagine 5 RIRs, A, B, C, D, E.
> Imagine in this scenario, that IAD is 1.5 years away.
> Run rates are:
> A = 5 /8's per year
> B = 3 /8's per year
> C = 2 /8's per year
> D = 1 /8's per year
> E = 1 /8 per 1.5 years.
This example, for simplification, also assumes all 5 RIRs are requesting
/8's at the same time.
> Assume some non-linear aspect to run rates.
> Assume that based on current projections, the last 1.5 years will result
> in
> usage for RIRs of, respectively:
> A = 9.5 /8's
> B = 5.25 /8's
> C = 2.75 /8's
> D = 1.5 /8's
> E = 1.0 /8's
>
> And (in order to have this use up all the space), there are 18 /8's left.
>
> This policy would, at the moment in time that the slowest RIR needs
> exactly
> one /8, assign X-1 /8's or parts thereof, to each RIR.
>
> In this example, that would be:
> A = 8 /8's and 1 /9
> B = 4 /8's and 1 /10
> C = 1 /8's, 1 /9, and 1 /10
> D = 1 /9
> E = (nothing, because current estimate is 1 /8 *)
>
> (* - if at the time the decision is taken to implement the final
> assignments, the smallest RIR has more than one /8 estimated use, they
> would get that portion above the one /8, rather than nothing.)
>
> And then immediately, each of A, B, C, D, and E, get the last /8 each,
> exactly the way 2007-23 proposes.
>
> This would result in achieving the balance of 2007-23, and also being
> fair based on run rate. Everyone would have the same amount of time,
> and more than one /8 left with which to enact respective "final /8"
> policies.
>
> Apologies if this isn't totally clear; please ask for details on any
> aspect of this if you don't understand what is being proposed.
>
> It is basically, split the last of the pie fairly, when the smallest piece
> is big enough to "eat".
And to be ultra-clear on this, the pie is not completely divided out under
this proposal; it leaves one piece each, with the expectation that the
combined amounts (this proposal *plus* 2007-23) will result in each RIR
exhausting their respective pools of IANA-supplied addresses at the same
time, or within a very short window (i.e. the error range of the
projections of usage.)
Brian
More information about the ARIN-PPML
mailing list