[ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4
sleibrand at internap.com
Mon Oct 29 18:07:37 EDT 2007
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.
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:
> Mailing list subscription information can be found at:
> 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
> (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.
> 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
> 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
> 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.
More information about the ARIN-PPML