[address-policy-wg] FORMAL PROPOSAL: change of initial PA allocation size

Hi,


I very much agree that the requirement for receiving an allocation should be
lowered. This was discussed last month, but has something happened?
According to the newly published document ripe-288, 5.1 an ISP setting up as
LIR still must demonstrate "efficient utilisation of at least a /22 of
address space". An ISP able/willing to pay for setting up a LIR should
simply be granted an allocation. Of course the allocation size should be
determined on the basis of the LIR's future needs, and /21 would probably be
more appropriate for several small LIRs.

I understand that the current policy makes it possible for an enduser/ISP to
not get an allocation when setting up a LIR (if a /22 is not immediately
needed), but will be able to receive a /22 PA assignment from an upstream
and THEN using the /22 assignment as documentation be granted an
allocation... Not to mention all the time wasted on getting an assigment,
renumbering and so on, this does not make sense at all!

Hopefully this can be changed on the next meeting.



Med venlig hilsen/Best regards

Christian Rasmussen
Hosting manager, jay.net a/s

Smedeland 32, 2600 Glostrup, Denmark

Email: noc at jay.net
Personal email: chr at corp.jay.net
Tlf./Phone: +45 3336 6300, Fax: +45 3336 6301

Produkter / Products:
http://hosting.jay.net

> -----Original Message-----
> From: address-policy-wg-admin at ripe.net
> [mailto:address-policy-wg-admin at ripe.net]On Behalf Of Titley, Nigel
> Sent: 24. oktober 2003 15:20
> To: Gert Doering; address-policy-wg at ripe.net
> Subject: RE: [address-policy-wg] FORMAL PROPOSAL: change of initial PA
> allocation size
>
>
> Gert Doering wrote:
> > Hi,
> >
> > this was discussed on the list before the last RIPE meeting, and we
> > had it on the address policy working group meeting (presented by me).
> >
> > I think we mostly have consensus on this issue, but I want to present
> > it as a formal proposal, before it's incorporated into the policy.
>
> I am strongly in favour of this, it helps to solve the
> bootstrapping problem
> that many small LIRs suffer from, and which many have to lie about to get
> around.
>
> >
> > PROPOSAL:
> >
> >   * the minimum initial allocation size (for new LIRs) is reduced from
> >     a /20, as of today, to a /21.
> >     (If a new LIR can demonstrate need for a bigger initial
> >     allocation, they can get a larger address block.  This will not
> > be changed).
> >
> >   * the requirement to show an immediate need for 25% of the allocated
> >     address space is removed for the "minimum initial allocation"
> >
> >
> > The motivation for that is that under the current policy, startup LIRs
> > that do not already hold address space cannot get an initial
> > PA allocation
> > (which would be a /20 as of today, or bigger), because in
> > many cases, they
> > cannot demonstrate immediate need, or prior utilization of sufficient
> > address space.
> >
> > To work around this, many startup LIRs use PI address space
> > as a start,
> > and when they have filled enough of this, apply for their own
> > PA again.
> > The problem with this is that in the end, it's very likely that more
> > than one route will end up in the global BGP table (where one PA route
> > would be sufficient), and also it encourages lying to the
> > RIRs (PI space
> > must not be distributed to third parties, i.e., LIR customers).
> >
> >
> > The drawback of the changes are that it's potentially wasting address
> > space for "very small LIRs" (that would be happy with a /23 PI space
> > and will now get a "huge" /21).  The wastage would only happen for
> > very small LIRs that will never grow to fill the initial /21.
> > A rough calculation shows that "1000 new LIR /21 allocations" would
> > need a /11, which is not an unbearable strain on the conservation
> > side, judging from the total number of LIRs in RIPE land today.
> >
> > A second drawback of this is that people may need to adapt their BGP
> > filters to permit /21s from the network block(s) where these
> > allocations are made from.  So the RIPE NCC needs to document this
> > accordingly, and ideally, well in advance.
> >
> > Gert Doering
> >         -- NetMaster
>
>
>
> **********************************************************************
> This e-mail message is confidential and is intended only for the
> use of the
> individual or entity named above and contains information which
> is or may be
> confidential, non-public or legally privileged. Any dissemination or
> distribution of this message other than to its intended recipient is
> strictly prohibited. If you have received this message in error, please
> notify us by email to postmaster at flagtelecom.com immediately and
> delete the
> original message and all copies from all locations in your
> computer systems.
>
>
> This e-mail has been swept by Mailsweeper TM for viruses. However, FLAG
> Telecom cannot accept liability for any damage which you may sustain as a
> result of software viruses.
> **********************************************************************
>
>
>
>