Hi All, I would like to raise a topic for discussion Re: recent changes to RIPE-230. Specifically, 3.2. Address Space requirements (see also http://www.ripe.net/ripencc/new-mem/flowchart3.html) In order to receive an initial allocation, an LIR needs to demonstrate either the utilisation of a minimum /22 (1024 addresses), or an immediate need for an assignment of at least a /22 . This can include your own infrastructure as well as your customers' networks that will be renumbered into your allocation == As a MSP we have many Enterprise customers who come to us for their colocation/remote hands needs. They also want reliable Internet, no point outsourcing if your data sits on an island. In the absence of a tested/reliable/accepted alternative, this means they want to Multihome. If they're sufficiently large we can process their application for PI space and send them on their way. However in a dedicated enterprise hosting environment many don't qualify, those that do are often not making a lot of use of their allocation once operational. We would like to offer a redundant multihome(ing) service, essentially creating an aggregation point for smaller clients and we take supply from our carriers who can focus on wholesale. This also services those that want small mb volume of traffic who generally aren't serviced by our colocated wholesale carriers because of the overheads vs revenue of servicing a mb or two. So: De-aggregating our /20 is not an option. Some providers filter. 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.