[ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 - AC postponed decision
Member Services
info at arin.net
Tue Nov 20 13:51:05 EST 2007
- Previous message: [ppml] Policy Proposal: IPv6 Assignment Size Reduction - AC did not accept
- Next message: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d - AC postponed decision
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 15 November 2007, the ARIN Advisory Council (AC) postponed their decision regarding "globally-coordinated-RIR-pie-IPv4" in order for the shepherds to work with the author. The AC will review this proposal at their next regularly scheduled meeting. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/submission_archive.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html 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
- Previous message: [ppml] Policy Proposal: IPv6 Assignment Size Reduction - AC did not accept
- Next message: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d - AC postponed decision
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list