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

[Scott Leibrand]

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.
    * I'm not sure of the necessity for this level of optimization in
      the final IANA allocations.
    * 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.

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