RIPE-185

[Alan Sawyer <]

Hi All,
I would like to discuss changing 5.2.1 of the ripe-185 document.
(this also refers to earlier RIPE-230 remarks)

Specifically,
5.2.1

>>>
 The minimum allocation size allocated to LIRs is a /20 (4096 addresses),
according to the slow-start mechanism described below. It is expected that
this prefix is announced as one aggregate. Allocations are made to LIRs
that meet one of the following criteria:

A. The LIR must demonstrate previous efficient utilisation of at least a
/22 (1024 addresses).

Or

B. The LIR must demonstrate an immediate address space need of at least a
/22 (1024 addresses.)

Additionally, if current address space held by the LIR amounts to a /22 or
less, then the LIR is required to renumber its address space into the
allocation it receives from the RIPE NCC.<<<



==

MSP's have many Enterprise customers who
come to them for their colocation/remote hands needs. 
Customers 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-185 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 5.2.1 from RIPE-185 

*OR*

Allow a PA allocation of /21 and Remove 5.2.1 from RIPE-185
<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.>

As we know deaggregation is not possible particularly as more and more
providers filter based on RIPE boundaries (also recent discussion on
SWINOG list)

*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. Until this is changed some businesses are commercially
disadvantaged by this policy. Don't get me wrong, the last thing I want to
do is contribute to unused space or bigger routing tables but there must
be a solution.

With Thanks.
Alan.