Hi Alan, I have not seen anybody answering. The changes in RIPE-230 have been discussed last year on this list. I objected to the initial allocation criterion as well, but was nearly alone and I admit, had no better proposal. Nowadays when becoming a LIR, you have to multi-home one of your upstream's PA space before you reach the /22 limit, or you request PI from RIPE (I have not done this, but this would be my proposal). <SNIP>
So: De-aggregating our /20 is not an option. Some providers filter.
No, that's the only solution I can see. Nobody is filtering on allocation boundaries, because partition is the only way to multi-home. RIPE-230 aims at *conservation* of IP space. Aggregation will suffer. You should request additional ASNs and assign (or have assigned) multiples of /24 to each of your PoPs/networks. Does this help? Karsten
Taking the same set of suppliers, de-aggregating to them and having our upstream announce our aggregated block is not an option because of our footprint and our desire to be open in terms of suppliers.
So to go forward we need to:
1. Register as an LIR at a country level (as we, as a single LIR do not qualify for multiple PA assignments under current assignment policy, even though this would be administratively easier for us)
*OR*
2. leased line connectivity (and no, not a tunnel across multiple AS's!!) between each country which simply introduces another POF, another cost overhead and increases the possibility of blackholing parts of your AS if an inter-country link fails. (remembering that our advantage is we have all these carriers on our doorstep aka ODF)
Justifying a /22 for immediate use is well, not possible. Customers won't wait to be provisioned until you have enough of them to use a /22 immediately.
Last year we applied to RIPE for LIR status and it was granted. If this were still last year I'd do the same at a country level.
However now RIPE-230 prevents this....
Possible (to bounce around) solutions are:
Use other quantitative methods for approving LIR status, i.e. what resources/capital investment will an LIR put into to ensuring their growth over a period.
aka 'the put your money where your mouth is' metric. && Remove 3.2 from RIPE-230.
*OR*
Allow a PA allocation of /21 and Remove 3.2 from RIPE-230 <lowers risk of waste should LIR be slow to reach expectations, also as the PA space exists in a LAN/MAN environment moving to /20 announcement later is trivial, no real migration.>
*OR*
Allow LIR to use PI space for locally colocated customers provided they are in a situation to pull the plug. (service operator) -
(possible flamebait, do we want more prefix's with less un-utilized space *or* less prefix's with higher un-utilized space in the short term? -- also migrating enterprise hosting clients from PI to PA later is hell, I imagine many will take the easy route and not bother until sufficiently pressured by RIPE/community.)
Would appreciate a constructive dialog on how this can be achieved.
With Thanks. Alan.