-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Leo, Leo Vegoda wrote:
Hi Andrea,
[...]
According to our experience only LIRs that needed a block much larger than /29 found it worth the effort to return their /32. I don't know how I should understand you statement. Should I take it to mean that the policy is impeding LIRs who would otherwise qualify for larger allocations from getting them because they will have to renumber their whole network? Or something else? There are a number of LIRs who received a /32 in the past who later realise that they might have qualified for a larger initial allocation. We allow these LIRs to return their /32 and then evaluate their request based on the data they submit.
In the event that the LIR plans to qualify for an allocation that will fit inside the /29 you have reserved for them, do you allow them to receive a block from the same /29? That is, do you allow them to do the "return and new initial allocation" as a book keeping exercise or will they normally need to renumber?
We treat "return and new initial allocation" the same as a normal initial allocation request. This includes, as with all initial allocation requests, reserving space for future growth, in the past by reserving three bits and currently using the binary chop algorithm. Simply expanding an LIR's current allocation would constitute an additional allocation and would follow the established additional allocation policy and procedure and would require the LIR to demonstrate that they have utilised their current allocation up to the threshold defined by the HD-ratio. Should it turn out that an LIR who received a /32 since the implementation of the binary chop algorithm would have qualified for a larger allocation, we could consider allocating the "new" larger block overlapping with their /32. However, most of these "return and new initial allocation" cases concern relatively old /32 allocations so we do not expect to have to do this very often, if at all. Best regards, Andrea Cima RIPE NCC
Thanks,
Leo
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk4paxoACgkQXOgsmPkFrjP0BQCcDIbhGhqIr6O2UiGhpQ+tUiTs TRYAn3dWTKCkuPU6T0ORQyVg2L9LRd5L =z6MP -----END PGP SIGNATURE-----