[address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
- Previous message (by thread): [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
- Next message (by thread): [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Richard Hartmann
richih.mailinglist at gmail.com
Mon Sep 14 10:14:39 CEST 2015
On Mon, Sep 14, 2015 at 9:17 AM, Radu-Adrian FEURDEAN <ripe-wgs at radu-adrian.feurdean.net> wrote: > 1. Separate pools or single pool > a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per > LIR) and a "recovered space pool" containing all space received from > IANA as "recovered and redistributed space" (for extra allocations) - > APNIC-like separation of pools > b. treat all addressing space available for allocation as a single > pool The only reason I can see is to keep the unused, continuous blocks in 185.0.0.0/8 if we ever need them for something else and thus try to get rid of the recovered pool first. > 2. Conditions for allocation the first /22. > - none (keep the situation as it is today - our preferred option) > - something else (please detail) "First"? This already implies a change afaict. > 3. Further allocation(s) (after the first /22) > 3.1 introduce some minimum delay after the last allocation : 12 months > (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less > ? None ? > 3.1.1 Does that mean one can get a new allocation every X months > (LACNIC-style) while the stock lasts ? > 3.2 Allocation size : /22 ? /23 ? variable depending on how much is > available at the time of allocation, max /22, min /24 (which does imply > a little more policy text in order to detail this) ? > 3.3 Additional conditions > 3.3.1 "LIR did not perform an outbound transfer" (do you think it > would make sense to have this condition for the first allocation too) > ? > 3.3.2 Other conditions ??? Why change it? This means that everyone will optimize for the maximum size in whatever way they can. And that's without the "I only got /n+1, while foo got /n, that's unfair" and the much-beloved "/n is not enough; let's increase to /n-1 as we already did once" (once==the proposal in this thread). If people want to get something longer than a /22, that might be a valid use case, but I am not convinced there will be enough to merit a pdp for this. Point in case: I helped an entity to become a LIR as they needed one /24. Within two months, they had an actual, valid use case for a second /24. If I had gotten them a /24 instead of a /22, we would then have had to jump through the hoops again. That's why a flat "no need, just /22" policy makes it simpler; even if it's wasteful in some cases. Richard
- Previous message (by thread): [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
- Next message (by thread): [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]