[address-policy-wg] New Policy Proposal (PI - PA Transfer)

Hi Tore,

On 10/10/13 1:20 PM, Tore Anderson wrote:
> Hi Andrea and thanks for the update!
>
>> This would allow for PA allocations smaller than the minimum
>> allocation size. It is our understanding that this last point would
>> require a policy change.
> Out of curiousity, how did these come about then?

These are 'historical' allocations, issued a long time ago. Please find 
the details below.

> ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated

This block was issued according to ripe-211. At that time, users requesting an allocation smaller than the default allocation size were issued an allocation from the blocks reserved for PI assignments.


> ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated

The actual entry in the RIPE Database is 193.218.208.0 - 193.218.221.255.


> ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated

The actual entry in the RIPE Database is 194.117.0.0 - 194.117.49.255.


> ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated

The actual entry in the RIPE Database is 194.153.192.0 - 194.153.213.255.


The delegated stats show allocations only on bit boundaries, resulting in multiple entries for allocated PA ranges that are not on bit boundaries.

For example, 194.153.192.0 - 194.153.213.255 would be aggregatable on the following bit boundaries:

194.153.192.0/20      194.153.192.0 - 194.153.207.255 [4096]
194.153.208.0/22      194.153.208.0 - 194.153.211.255 [1024]
194.153.212.0/23      194.153.212.0 - 194.153.213.255 [512]

This results in having the IP range 194.153.192.0 - 194.153.213.255 as three separate entries in the delegated stats file. We can look into changing the format output of the delegated stats file if this is considered to be a problem.


>
> FWIW, I've always considered the minimum allocation size the minimum
> size *that the RIPE NCC may allocate* - not the minimum allocation size
> that may exist in the database at a given point in time.

The Registration Services Department has always been clear that we interpret the policy as "the minimum size of allocated PA address space". This is true both when the address space is issued as well as after it has been issued. That this is the intended spirit of the policy can also be found in section 5.5 of ripe-592, according to which allocations cannot be broken into IP blocks smaller than the minimum allocation size for transfers: "The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation".

You can find the relevant section here:
http://www.ripe.net/ripe/docs/ripe-592#Transfers-of-Allocations


> The existence
> of the above four allocations appears to preclude the latter
> interpretation in any case.
>
> With the former interpretation PI->PA conversions for blocks smaller
> than the minimum allocation size is quite OK by policy, as it isn't an
> allocation performed by the RIPE NCC from the free pool. Besides, I
> can't think of any reason for having a minimum allocation size in the
> first place except to prevent deaggregation, but these as those PI
> blocks are already deaggregated that's not applicable here either.

Please understand that I am not disputing your reasoning or opinion. We base our procedures on policy text that is set by the RIPE community. If the RIPE community believes that a policy is no longer relevant and changes this through the PDP, the RIPE NCC will change its procedures accordingly.


Best regards,
Andrea Cima

RIPE NCC


> IMHO, anyway...
>
> Tore
>