[arin-ppml] IPv4 Fragment Managemnt policy proposal

[John Santos]

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.

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

Maybe this is mathematically impossible, or statistically very
unlikely?

But the point is the policy shouldn't force unnecessary deaggregation.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539