Re: [sig-policy] Prop-098 Revision 2 (redlined version showing changes f
About changing HD-ratio based allocations
* Can raise awareness on allocations larger than /32 by improving
guidelines, webpage
* You can see the HD-ratio chart, so it is not complicated
* % Utlization in HD-ratio is low today, so not being a barrier
About nibble boundary based allocations
* There may possibly be an operational benefit if assignment size is
nibble boundary based. ISPs can make this decision without defining
by policy
Basicallly, they weren't able to relate to the needs.
Perhaps, some of the problems can be solved by improving the wordings in
the policy document or guidelines, to make it clear that ISPs can
request for larger than /32 from initial allocations?
Against the proposal based on the reasons above.
Izumi/JPNIC
(2012/02/02 7:20), Owen DeLong wrote:
> The text below uses the following typographical conventions:
>
> Text in black is unchanged from the previous version.
> Text in blue is new text added in this version.
> Text in red strikeout is text removed from the previous version.
> Text in green is modified from the previous version.
>
> ________________________________________________________________________
>
> prop-098-v002: Optimizing IPv6 allocation strategies (simplified)
> ________________________________________________________________________
>
>
> Author: Owen DeLong
> <owen at delong dot com>
>
> Version: 2
>
> Date: 1 February 2012
>
>
> 1. Introduction
> ---------------
>
> This is a proposal to allow for more generous IPv6 allocations to
> service providers in order to promote better aggregation and easier
> optimization across their networks as they grow.
>
>
> 2. Summary of current problem
> -----------------------------
>
> 2.1. Many LIRs are of the errant belief that they must fit their entire
> subscriber base within a single /32 and that they cannot easily
> obtain larger allocations from their RIR or NIR.
>
> 2.2. Many network outages have been caused by on-the-fly bit math errors
> and by aligning addressing blocks on nibble boundaries, at least
> where it makes sense, these errors can be reduced or eliminated.
>
> 2.3. Continued proliferation of the /32 mindset described in (1) above
> will eventually lead to significant unnecessary disaggregation and
> larger IPv6 routing tables.
>
> 2.4. The HD ratio, while a good mathematical model leaves much to be
> desired as an address administration tool. Using nibble-boundaries
> and rounding up actually yields similar results with simpler math.
>
>
> 3. Situation in other RIRs:
> ---------------------------
>
> ARIN:
>
> - Adopted, awaiting implementation by staff.
>
> RIPE:
>
> - As RIPE NCC seems to be currently issuing generous allocations,
> the author does not currently intend to submit a proposal to
> RIPE. However, the author may subsequently submit a policy to
> align RIPE allocations on nibble boundaries.
>
> LACNIC and AfriNIC:
>
> - Author is working on proposals for these regions.
>
>
> 4. Details of the proposal
> ---------------------------
>
> Amend IPv6 allocation policy as follows:
>
> 1. Add the following definitions:
>
> Nibble boundary: The point in a binary string where one hex digit
> ends and another begins.
>
> Provider Allocation Unit: The unit by which an LIRs utilization is
> measured. It is defined as the smallest reassignment unit used by
> the provider.
>
> 2. Redefine the following terms:
>
> End site:
> A single structure or service delivery address, or a
> single tenant within a multi-tenant structure.
>
> - The intent of this definition is to provide greater clarity and
> flexibility in allowing ISPs to meet the needs of their
> customers.
>
> Utilized:
> (i) A provider allocation unit shall be considered fully
> utilized when it is assigned to an end site or allocated to a
> customer LIR.
>
> (ii) The utilization percentage of a block at the LIR level is
> calculated as the fraction of total provider assignment units
> which have been assigned to end sites or allocated to
> customer LIRs.
>
>
> 3. Make all allocations and assignments on nibble boundaries.
> 3. Allow all requesters to round their requests up to the next nibble boundary.
>
> 4. Allow LIRs to request nibble-aligned blocks of any size greater than
> or equal to /36.
>
> 4.1 The default minimum is /32 unless the provider specifically
> asks for a /36.
>
> 4.2 The maximum allocation shall be the smallest nibble aligned block which allows
> the provider to accommodate 5 years of projected customer
> utilization based on assigning each customer end-site one
> provider allocation unit without exceeding a 75% utilization. If
> the provider has no allocation or assignment history, the
> provider may specify their provider allocation unit at the time
> of application.
>
> 4.3 An LIR which has subordinate LIRs may count the required
> allocation for each subordinate LIR as fully utilized blocks of
> PAUs in the calculation for 4.2.
>
> 5. Modify the subsequent allocation process.
>
> 5.1 To qualify for a subsequent allocation, an LIR must meet one of
> the following two criteria:
>
> - 75% or more utilization of their total address space, OR
>
> - One or more facilities which have reached a 90% utilization of
> the blocks allocated to those facilities and there are no
> available blocks of sufficient size in the providers current
> allocation(s) to expand those facilities and/or add new facilities.
>
> 5.2 When making a subsequent allocation, APNIC will use the
> following procedure:
>
> Whenever possible, expand one or more existing allocations to
> the next nibble as needed.
>
> When the above expansion cannot meet the need, make a new
> allocation large enough to encompass all existing allocations
> plus the need justified in this request.
>
> Such allocation shall not exceed a /16, but, a provider may
> receive as many /16s as are required to meet their justified
> needs.
>
> When this occurs, an LIR is encouraged to vacate their old
> allocations through attrition and return vacated space when
> feasible. The LIR is not required to vacate the space, but, it
> is encouraged. Once vacated, the space should be returned.
>
> Nothing in this section shall preclude a requestor's right to expand on nibble-boundary alignments if that is desired.
>
> 6. Allow LIRs with existing allocations to expand their allocation size
> if they are eligible for a larger block under the criteria in this
> proposal.
>
> Any LIR which received an allocation under previous policies which is
> smaller than what they are entitled to under this policy may receive
> a new initial allocation under this policy based on the procedure and
> criteria in 5.2.
>
>
> 5. Advantages and disadvantages of the proposal
> ------------------------------------------------
>
> Advantages:
>
> - Provides nibble-boundaries for direct allocations and for at
> least one level of network hierarchy within the LIR, reducing the
> potential for human factors errors.
>
> - Increases the potential for network aggregation by issuing very
> large blocks to ISPs.
>
> - Reduces the potential for harmful under-sized assignments to end
> users by removing any incentive to do so.
>
> - Simplifies the IPv6 allocation policy by removing logarithmic
> computations in favor of simple ratios.
>
> - Reduces the number of times any given LIR will need to return to
> APNIC for additional allocations.
>
> - Allows for better network planning and growth.
>
> Disadvantages:
>
> - May increase IPv6 address allocation. Probable impact over 50
> years would reduce IPv6 free pool from 99.9995% to 99.62%.
>
>
> 6. Effect on APNIC Members
> ---------------------------
>
> APNIC LIR members will be able to obtain significantly larger blocks of
> IPv6 addresses and both receive and make their initial allocations and
> assignments on nibble boundaries to simplify human factors and network
> management while improving aggregation.
>
>
> 7. Effect on NIRs
> -----------------
>
> This policy should not significantly impact NIRs.
>
>
> 8. References
> -------------
>
> [1] Section 5.5, 'Assignment', in 'APNIC IPv6 Allocation Policy'
> http://www.apnic.net/policy/ipv6-address-policy#5.5
>
>
>
>
>
>
>
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy