Re: [address-policy-wg] FORMAL PROPOSAL: change of initial PA allocationsize

[Sascha Lenz <]

Hay,

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.
>
>
> 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"
whereas I do support this for the given reasons which already have been 
discussed on the list(s) and during the RIPE Meeting, i - again - want 
to raise some side-effect this might have together with another proposal 
 that goes with this one: no more (newly assigned) PI space.

Reducing the minimum allocation size + Very-Small RIPE membership is a 
nice thing for small/start-up companies, but still a problem for 
very-very-very-small non-commercial organisations or 
very-very-very-small not-so-commercial companies.

I still fear this might lead into the situation that those can't get any 
independant IP-Space anymore at all.
This might also be a negligible issue for most people here, but at least 
i want to raise it again.

I wouldn't like to see than an organisation isn't able to get 
independant IP-space for monetary reasons, as long as they can show good 
reasons why they need it.

So, there should be some exceptions here, for example (even more) 
reduced LIR fee for non-commercial organisations or possibility to get 
some addresses out of the swamp-space in those cases but no PI space in 
general anymore - or whatever.
I don't nescessarily want to complicate the policy again, so i don't 
give details of how this might be implemented now, but one should keep 
this in mind for later discussions.

Probably this really should be discussed seperately though, so please if 
you want to reply on this one - use a different Subject.
Back to the proposal we have right here:

[...]
> 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.
I do not see any wastage here, at least no important one.
Reason: I don't see any need for conservation of IPv4-space anymore.
        There is IPv6 now, it works, people can implement it.
        The sooner IPv4 space runs out, the better actually.
        AND - you all heard the prediction about IPv4 space lasting
        some more decades during the RIPE meeting (nice presentation :)

==> This "drawback" is none for me.

> 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.
That's a bigger problem. I'd say RIPE shouldn't start allocating
smaller Prefixes from the existing /8-blocks, but rather get a new
one from IANA and start _there_

You all know it's probably not possible to reach all Network 
Administrators in time to change their filters, some don't even care.
This has happend often enough during the last years, one shouldn't even 
think about it :-(

...my 0.02EUR

--
========================================================================
= Sascha 'master' Lenz         SLZ-RIPE          slz@localhost         =
= NOC BayCIX GmbH                                                      =
= http://www.noc.baycix.de/              * PGP public Key on demand *  =
========================================================================