Hi Tore,
Also for the sake of the argument I'll make the assumption that the reserved pool is activated when it contains a /10, both because that's a figure you've mentioned earlier, and also because waiting until it contains a /9 will in all likelihood mean it will sit there inactive for years, and that won't help anyone either.
First, let's try with a max allocation size of /22. Then there would be 4096 /22s in the pool, enough for all of the LIRs you want us to take care of.
Something about this worries me. I am afraid we will end up with more 'types' of LIRs: - the old ones that could request whatever they needed - the ones that started just before runout who have one /21 and one /22 - the first 4096 that started just after runout who have two /22s - the later ones that have one /22 The first 4096 of last category could potentially get another /22 when/if the pool reaches a /10 again, but as you say this will take years. This doesn't feel right. If we make a policy to give more IPv4 addresses to the LIRs that only have one /22 then it should be: - equal for all of them - sustainable for a long time If we can do this then I don't see a problem, but in order to do this the returned pool has to be able to grow to (almost) a /8 because otherwise we won't be able to give every LIR with one /22 their second /22. And that will create unfairness again... Cheers, Sander