RIPE-230
- Date: Sat, 2 Feb 2002 00:54:08 +1100 (EST)
Cross posted for comments.
A-
---------- Forwarded message ----------
Date: Tue, 22 Jan 2002 23:41:32 +1100 (EST)
From: Alan Sawyer alan@localhost
To: lir-wg@localhost
Subject: RIPE-230
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.
