[arin-ppml] IPv4 Fragment Managemnt policy proposal

[Owen DeLong]

On Apr 29, 2010, at 7:40 PM, John Santos wrote:

> On Thu, 29 Apr 2010, Owen DeLong wrote:
> 
>> 
>> 
>> I can understand the "bitmath is hard let's go shopping" concept if
>> the applicant was going to need to identify the largest available
>> sub-blocks, etc. However, this is very simple from the end user's
>> perspective.  All the "hard math" is handled by ARIN's systems.
> 
> Um, I think that what people were objecting to was the proposal
> (requirement of bit-aligned blocks) would make it impossible for
> ARIN to expand existing blocks when possible, which is current
> policy.
> 
> For example, if a org has a /18 and qualifies for an additional
> /16 (4 more /18s) and the /16 that starts with their current /18 is
> available (as a /18 and a /17), then currently ARIN would assign
> /allocate theremainder of the /16 and the org would have effectively
> plus another /18 to get them their full allocation in only 2 blocks.
> But the bit-alignment criteria would apparently force ARIN to treat
> the /16 (3/4ths of which is available) as a /18 followed by a /17,
> or as 3 /18s, with org potentially ending up with 4 random /18s.
> In this case, its a wash since they don't go over their 4-block
> limit, but I can imagine there are many cases where if they hold
> multiple blocks, several of which could be extended, their would
> be unnecessary fragmentation.
> 
Ah... That is outside of the intent.  I will review and revise the
proposal to account for this.  The intent is to prevent ARIN from
granting someone a new allocation which contains 1.5 /20s
taken from a clean /19 or something like that.

> I think a single clause saying that extending an existing address
> block counts as single block under the 4-block limit of this
> proposal (in cases where even if the additional block(s) aren't bit
> aligned, the resulting block, including the original block, is
> aligned.)
> 
Agreed.

> Maybe this is mathematically impossible, or statistically very
> unlikely?
> 
I suspect in the end game, block extensions will be very rare, indeed.

> But the point is the policy shouldn't force unnecessary deaggregation.
> 
Agreed.  The intent of the bit-alignment clause was to prevent, not
create unnecessary deaggregation. I believe that section 8.3 will
do more than enough of that.


Owen