minimum allocation size in case of transform addresses
Hi! I found today out, that there is planed possibility to convert PI assignments to PA allocation. But - i'ts planed only for /22 and bigger assignments, due to minimum allocation size, and doesn't apply for example /23 or /22 assignemnts. I think it's a bit pointless. AFAIK sense of minimum allocation is suppression of unnecessary fragmentation. But - in this case - this pool is already in use, and is already visible in bgp table. Allowing or disallowing conversion doesn't have any relation with growing address space. What's more - allowing conversion of any assignment can save some of address space. Most of PI assignemts (known to me) is partialy unused. After years from assignemnts part of the plans has been withdrawn (but another parts are citical - dns servers etc - so whole assignemnt can't be returned). Allowing conversion would allow use it back, for example for customers... (sorry for my english - i hope that sense is understandable) -- Regards, Andrzej 'The Undefined' Dopierała http://andrzej.dopierala.name/
On 3/25/13 17:21 , Andrzej Dopierała wrote:
Hi! I found today out, that there is planed possibility to convert PI assignments to PA allocation. But - i'ts planed only for /22 and bigger assignments, due to minimum allocation size, and doesn't apply for example /23 or /22 assignemnts.
I think it's a bit pointless.
AFAIK sense of minimum allocation is suppression of unnecessary fragmentation. But - in this case - this pool is already in use, and is already visible in bgp table. Allowing or disallowing conversion doesn't have any relation with growing address space.
What's more - allowing conversion of any assignment can save some of address space. Most of PI assignemts (known to me) is partialy unused. After years from assignemnts part of the plans has been withdrawn (but another parts are citical - dns servers etc - so whole assignemnt can't be returned). Allowing conversion would allow use it back, for example for customers...
(sorry for my english - i hope that sense is understandable)
You probably still want to prevent the fragmentation of larger blocks into smaller blocks than the applicable minimum allocation size. However, if the block in question is already smaller then it should be transferable at its current size, you just can't fragment the block. Legacy /24s or PI blocks are easy examples of block that exist that you might want to all an LIR to receive. Language like the following should work; "The minimum transfer size is the smaller of the original allocation size or the applicable minimum allocation size in current policy." This is one reason to not completely eliminate all the existing IPv4 policies with 2013-03. They can still be useful, and may be useful in the future. Otherwise, you have to revisit the consensus for issues like what the appropriate minimum allocations size should be in what situations. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================
* Andrzej Dopierała
I found today out, that there is planed possibility to convert PI assignments to PA allocation. But - i'ts planed only for /22 and bigger assignments, due to minimum allocation size, and doesn't apply for example /23 or /22 assignemnts.
I think it's a bit pointless.
Agreed. If the assignment is smaller than the minimum allocation size to begin with, I don't see any harm in allowing one to convert to PA completely as long as it's a one-to-one swap that does not cause further deaggregation. For what it's worth, there are already several allocations smaller than the minimum allocation size in effect at the time they were made: ripencc|GB|ipv4|79.143.80.0|1024|20120810|allocated ripencc|GB|ipv4|79.143.84.0|1024|20120810|allocated ripencc|FR|ipv4|82.196.24.0|1024|20031027|allocated ripencc|FR|ipv4|82.196.28.0|1024|20031027|allocated ripencc|BG|ipv4|84.238.192.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.196.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.200.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.204.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.216.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.220.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.224.0|1024|20040810|allocated ripencc|BG|ipv4|84.238.228.0|1024|20040810|allocated ripencc|CZ|ipv4|91.201.20.0|1024|20080123|allocated ripencc|DE|ipv4|128.0.152.0|1024|20120914|allocated ripencc|IL|ipv4|192.114.84.0|1024|19990603|allocated ripencc|SE|ipv4|193.108.42.0|512|20010406|allocated ripencc|DE|ipv4|193.218.216.0|1024|19981110|allocated ripencc|DE|ipv4|193.218.220.0|512|19981110|allocated ripencc|PT|ipv4|194.117.48.0|512|19941206|allocated ripencc|IT|ipv4|194.153.208.0|1024|20000509|allocated ripencc|IT|ipv4|194.153.212.0|512|20000509|allocated ripencc|PL|ipv4|195.140.236.0|1024|20031001|allocated ripencc|DE|ipv4|213.153.80.0|1024|20000324|allocated ripencc|DE|ipv4|213.153.84.0|1024|20000324|allocated I don't know why and how they came about, but they're there at least. * David Farmer
This is one reason to not completely eliminate all the existing IPv4 policies with 2013-03. They can still be useful, and may be useful in the future. Otherwise, you have to revisit the consensus for issues like what the appropriate minimum allocations size should be in what situations.
Please read 2013-03 more carefully. It retains the concept of a minimum allocation size. It does change it from the obsolete and incorrect /21 (which hasn't been true since the implementation of the last /8 policy) to the correct /22, though. Quoting from the proposed policy: «The RIPE NCC's minimum allocation size is /22». When it comes to assignments, there is currently no minimum size defined in the policy, and 2013-03 does not change this in any way. That said, ripe-555 documents that: «The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29». Tore
participants (3)
-
Andrzej Dopierała -
David Farmer -
Tore Anderson