[arin-ppml] [Remco.vanMook at eu.equinix.com:[address-policy-wg]new policy idea for PA allocations]

[Darden, Patrick S.]

As usual, Michael is spot on:

http://www.arin.net/policy/nrpm.html#six1

"6.3.4. Aggregation

Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables.

This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing.

IPv6 address policies should seek to avoid fragmentation of address ranges.

Further, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation."


--Patrick Darden



-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]On
Behalf Of michael.dillon at bt.com
Sent: Thursday, August 07, 2008 2:10 PM
To: ppml at arin.net
Subject: Re: [arin-ppml]
[Remco.vanMook at eu.equinix.com:[address-policy-wg]new policy idea for PA
allocations]


> The first question is simple: If the policy stays as-is, what 
> does staff intend to do when they get a request larger than 
> they can provide in a single block?

Today, as you know, staff reserves neighboring blocks in case
the same ISP comes back in 6 months for more. That way they
increase the size of an existing block by aggregating neighboring
CIDR blocks.

There was one instance where I asked for a /16 and it was approved,
but they gave me two /17 blocks instead. The first /17 filled out
was previously reserved and filled out a /15. The second /17 was
from a completely different /8.

Staff don't seem to be anal about this, i.e. they give you blocks that
add up to what was approved. One would think that they would continue
this behavior when they run out of big blocks.

--Michael Dillon
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.