[ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4

[Brian Dickson]

Scott Leibrand wrote:
> Brian,
>
> A few comments:
>
>    * I think this has to be a true global policy (passed in identical
>      forms in all 5 RIRs), because it directs IANA action.  If I
>      understand the policy process correctly, that's different from a
>      "globally coordinated" policy.
You may be right there. I am a bit unsure of which it needs to be, 
and/or how an IANA policy would get proposed/approved.
I think if the 5 RIRs agree to the policy, they can just ask IANA to 
implement it.
>    * I'm not sure of the necessity for this level of optimization in
>      the final IANA allocations.
It removes "blind chance" from the final allocations.
There may be a presumption that the last allocations will give the 
slowest-using RIRs the most time, but there could be disparity among the 
two or three slowest that was neither intended nor forseen.

If the two slowest get one block each, but one of them had *just* 
received its previous block, and the other was *just* about to exhaust 
its previous block, this would both appear to be unfair, and actually 
*be* unfair.

The proposed policy also balances the needs of the fast-using RIRs, 
mostly preventing fast-RIR customers from RIR-shopping. RIR shopping 
would cause, IMHO, lots of problems, including an even greater problem 
of proliferation of difficult-to-trace ownership of IP blocks used for 
nefarious purposes (e.g. spam).

The good that comes out of the policy is an expected side-effect, but 
mostly it's about predictability and fairness.

If everyone expects their personal IED day to be the same as global IED 
day, there should be no surprises. It reduces the IED to a Y2K-like event.
>    * Your mechanism for triggering the pie-splitting event seems to
>      assume that every request will be for two /8s.  Your proposal
>      states that "If the RIR projection shows that the RIR would not
>      expect to use up _two /8 blocks_ before IED, the "Pie-splitting"
>      event will be triggered."  You might want to rephrase "two /8
>      blocks" to something like "the requested allocation".  That way,
>      if a slow-consuming RIR only requests one /8 (because they can't
>      use up two before IED), then we don't prematurely trigger
>      pie-splitting.  Please let me know if I'm misunderstanding your
>      intent or the imlications of the "two /8 blocks" clause.
>
Ah, the magic "two".

It's only "two" because of the need to hold back one from the final 
allocation.
If you subtract the withheld one from the two, it becomes "one".

It's basically an attempt to word things without double-negatives and 
without double-entry accounting.

What it really means is:
- IANA holds back one /8 per RIR
- If the next /8 IANA gives to an RIR, *plus* the held-back /8, would 
last beyond IED, it's time to divide up the pie.

BTW - the most likely scenario is that one of the two *slowest* RIRs 
will trigger the pie event, specifically because each of their /8's 
lasts longer.

(And no, there is no presumption on multiple /8's per allocation. If 
anything, it's the reverse.)

Thanks for your comments.

Brian
> -Scott
>
> Member Services wrote:
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> The ARIN Advisory Council (AC) will review this proposal at their next
>> regularly scheduled meeting. The AC may decide to:
>>
>>     1. Accept the proposal as a formal policy proposal as written. If 
>> the
>> AC accepts the proposal, it will be posted as a formal policy proposal
>> to PPML and it will be presented at a Public Policy Meeting.
>>
>>     2. Postpone their decision regarding the proposal until the next
>> regularly scheduled AC meeting in order to work with the author. The AC
>> will work with the author to clarify, combine or divide the proposal. At
>> their following meeting the AC will accept or not accept the proposal.
>>
>>     3. Not accept the proposal. If the AC does not accept the proposal,
>> the AC will explain their decision. If a proposal is not accepted, then
>> the author may elect to use the petition process to advance their
>> proposal. If the author elects not to petition or the  petition fails,
>> then the proposal will be closed.
>>
>> The AC will assign shepherds in the near future. ARIN will provide the
>> names of the shepherds to the community via the PPML.
>>
>> In the meantime, the AC invites everyone to comment on this proposal on
>> the PPML, particularly their support or non-support and the reasoning
>> behind their opinion. Such participation contributes to a thorough
>> vetting and provides important guidance to the AC in their 
>> deliberations.
>>
>> The ARIN Internet Resource Policy Evaluation Process can be found at:
>> http://www.arin.net/policy/irpep.html
>>
>> Mailing list subscription information can be found at:
>> http://www.arin.net/mailing_lists/
>>
>> Regards,
>>
>> Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>> ## * ##
>>
>>
>> Policy Proposal Name: globally-coordinated-RIR-pie-IPv4
>>
>> Author: Brian Dickson
>>
>> Proposal Version: 1
>>
>> Submission Date: 26 October 2007
>>
>> Proposal type: new
>>
>> Policy term: renewable
>>
>> Policy statement:
>>
>> This policy concerns the globally-coordinated allocations of IPv4
>> address space from IANA to the RIRs.
>>
>> The policy is intended to be compatible with 2007-23 (in its expected
>> final form).
>>
>> The overview of the policy is:
>> At the last reasonable time to do so, divide up the remaining IPv4 space
>> based on currently projected use between that time and the date at which
>>   no more IPv4 space is available at any RIR for new allocations.
>>
>> Here is how the policy is to be implemented:
>>
>> 1) RIRs should provide up-to-date assignment projections for their
>> respective regions, and provide up-to-date utilization on their current
>> IANA-assigned block(s) from which assignments are made.
>>
>> 2) RIRs should provide an official projection on IANA Exhaustion Date
>> (IED) to the community through their website, at their Policy Meetings
>> and through any other effective means.
>>
>> 3) When any RIR requests a /8 from IANA, the current assignment
>> projections for that RIR should be combined with the RIR's currently
>> available IANA  blocks (i.e. from which RIR assignments are made). This
>> should be compared with the global available IANA unused space (for
>> allocating to RIRs), the current projected usage rate of the RIR, and
>> the current projected IED.
>>
>> If the RIR projection shows that the RIR would not expect to use up two
>> /8 blocks before IED, the "Pie-splitting" event will be triggered.
>>
>> 4) Splitting the Pie - the following method will be used to determine
>> the final IPv4 global IANA allocations to the RIRs:
>> For each RIR, the following calculation will be done:
>>      (i) Determine from the current projection, the total allocations
>> the RIR will make from present to IED
>>      (ii) Subtract from this, unallocated RIR space already received
>> from ARIN (if any)
>>      (iii) Round the result to the nearest /12
>>      (iv) Subtract from this amount, one /8 (to be set aside to satisfy
>> the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to
>> RIRs")
>>      (v) Allocate this amount to the RIR immediately. Every effort
>> should be made to divide these allocations among RIRs in as aggregatable
>> a fashion as possible.
>>
>> 5) The allocations made will result in just 5 * /8 being left in the
>> IANA pool, which will trigger 2007-23.
>>
>> 6) This in turn, will result in the last 5 * /8's being allocate to the
>> RIR's, one for each.
>>
>>
>> Rationale:
>>
>> The objective of this policy is to ensure that the remaining IPv4 pool
>> is distributed so as to provide each RIR with a quantity of IPv4
>> addresses that will last for an expected duration.
>>
>> The intent is for this duration to be as close to the same for each RIR
>> as possible.
>>
>> By following the rules above, the "pie split" is done:
>> - as late as possible
>> - as fairly as possible
>> - in a consistent manner for all RIRs
>> - early enough that each RIR is guaranteed at least one /8
>>
>> The final /8 allocations are done *after* this allocation, so that there
>> can be no issue of fairness, with each RIR being guaranteed to get one
>> of the final /8's at the same time.
>>
>> The "pie split" is timed so that no RIR will have so much (relative)
>> IPv4 address space, as to expect to have IPv4 space after any other RIR
>> has exhausted its own IPv4 space.
>>
>> By providing a "pie split" which is based on the same data as the IED
>> projection, the following results occur:
>> - there is no contention over the process by which the division of
>> resources occur
>> - all RIRs have the ability to project, well in advance of the "pie
>> split", exactly when their own IPv4 space will be exhausted. It will
>> happen at the IED date -- no sooner, no later.
>> - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land
>> grab" is likely to occur, and thus the projections for IED itself are
>> likely to remain consistent, as will the per-RIR projections.
>> - LIRs are likely to view the policy as neutral, and thus fair.
>> - Because it removes the incentive for RIR shopping, the rules
>> preventing RIR shopping will become largely moot (but still
>> recommended). The perception then of anti-shopping provisions might then
>>    be that it maintains stability, rather than penalizing any
>> RIR/LIR/region.
>>
>> Additional Observations about Fast vs Slow RIRs
>>
>> Fast-consuming RIRs will contribute more heavily towards the consumption
>> rate. In turn, these RIRs will be the largest component of the
>> projections of IED.
>>
>> Low-consuming RIRs will have less impact on IED. However, the low rate
>> means that these RIRs will have *greater* proportional accuracy when it
>> comes to knowing how much space they need between present time and IED.
>> (This is because, the uncertainty on allocation needs, will be the
>> result of multiplying the uncertainty on IED date, by the rate of
>> consumption. Low-consuming LIRs, will have less uncertainty on their
>> penultimate allocation.)
>>
>> The uncertainty on exact date of IED, is expected to be largely
>> invariant across RIRs.
>>
>> Any changes to individual RIR allocation trends, after the "pie split"
>> date, are not expected to exceed the individual RIR's own uncertainty at
>> "pie split" date. In other words, the accuracy of each RIR's IED is
>> expected to increase over time, and to continue to fall within the range
>> of the original upper and lower limits (based on rounding to /12) of the
>> RIR's allocation from IANA.
>>
>> Timetable for implementation: immediate
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
>> Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>