This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] About the /22 allocation limitation
- Previous message (by thread): [address-policy-wg] About the /22 allocation limitation
- Next message (by thread): [address-policy-wg] About the /22 allocation limitation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue Apr 15 23:33:27 CEST 2014
Hi Daniel, > please take care of the LIRs that only have a /22 and will never > recieve more from RIPE. We'd love to, truly, but I do not see how we can without having an abundance of available addresses to hand out. The math just doesn't work out. There are currently 1849 LIRs that you want us to take care of, i.e., they are holding only a single /22. Considering that almost all of these joined in the last 18 months, I think it is quite safe to assume that the number will be 2500 or more by the time your proposal would be implemented by the NCC, even if it were to pass the PDP in record speed. You have suggested that you do want the proposed new "reserved pool" to have a max allocation size, but have so far not said what it should be. So, for the sake of the argument, I'll make up some possible max allocation sizes below. 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. But, as I understand you've already noticed, a /22 doesn't last very long at all if you plan to hand out a "whole" address per subscriber (or more). Neither does a /21. So this doesn't really help much; /22 or /21, both are "not enough" - the change would not be worth the trouble. Also, if you consider the current LIR sign-up rate and assume that most of them will want all the IPv4 they can get their hands on while they still can, the entire pool would probably not lat a full year before being completely drained. Another reason why it wouldn't be worth the trouble. So, let's try with a max allocation size of /21 then. The /10 reserved pool would have 2048 /21s. But that is fewer /21s than the number of LIRs that would be eligible for receiving allocations from it. Oops. So with /21 (or greater obviously), we simply do not have enough addresses to take care of all the LIRs you want us to - and helping only a (randomly selected?) subset of them is much worse than helping none, IMHO, as it would create arbitrary inequalities and unfairness. Finally, in any case it would mean that we decide to burn through our remaining resources at the expense of the "future generations" to which those resources are currently earmarked. I do not think that would be wise at all. A proverb we have here in Norway about peeing one's pants in winter to warm up comes to mind... We should try to keep a /22 in reserve for those who decide to enter the business a decade from now too, and by the look of things, we might just succeed in that - IFF we don't fall for the temptation to pass policies such as the one you're proposing. Tore
- Previous message (by thread): [address-policy-wg] About the /22 allocation limitation
- Next message (by thread): [address-policy-wg] About the /22 allocation limitation
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]