AW: RIPE-230

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.
> 
> 
> 
>