Re: [address-policy-wg] Summary of the PI Task Force's recent discussions

[Daniel Roesen <]

On Mon, Aug 11, 2003 at 08:19:46AM +0200, leo vegoda wrote:
> Below is a summary of the recent discussions on the PI TF mailing list.

As the pi-tf mailing list seems to have been closed (at least I'm unable
to subscribe - pi-tf-request@localhost bounces as unknown), I guess
further discussion should take place here (which makes some sense).

> 1. Reduce the minimum allocation size from /20 to /21

Agreed.

> 2. Remove the requirement to show an immediate need for 25% of the
>     allocated address space (a /23 in this case)

Agreed.

> 3. No longer assign PI (Portable) address space to End Users

Strongly disagreed. Upstream-independent address space is _needed_.
This cannot be ignored.

> 4. End Users requiring a portable address block could become an LIR
>     and receive a /21 allocation.

An end-user can't be a LIR by definition. :-)

Let's take a look at four entity categories:

A) Commercial ISPs, assigning subnets to customers
B) Enterprises (from very small companies to multinational heavyweights)
C) non-commercial organisations (NCOs) being absolute end-users
D) non-commercial organisations (NCOs) assigning subnets to org members

Cat A is quite clear. They should become regular LIRs, receive an
initial allocation under provisions of #1 and #2 above. RIPE NCC efforts
are covered by LIR membership fees.

Cat B should be able to get an IP block according to documented need
plus some reserve (perhaps at least a /22 by default) without ability
to sub-assign subnets. RIPE NCC efforts are primarily one-time and
thus the requestor should pay a one-time fee for the request processing,
plus a periodic, moderate maintenance fee to cover administrative and
operational costs for their data in the RIPE systems like the RIPE DB.
Usually, those kind of entities are nowadays typical PI requestors
(getting IP space for free via a LIR), or Enterprise LIRs (paying
significant yearly fees, but not requiring any cost-intensive RIPE NCC
service like hostmaster support as no registry function is performed).

Cat C+D are most interesting. The aim for those should be to keep
cost as low as possible. Cat C would be typical PI requestors today,
with no fees to be paid at all. IMHO, we should keep this cost
neutrality for those kind of NCOs.

Cat D is where the fun starts.

Currently, Cat D NCOs would usually request larger PI blocks, and
"silently" (without documentation in the RIPE DB due to the nature of
PI assignments) sub-assign subnets to NCO members. As an example,
imagine a "computer club" having built a city-wide "club WAN" by
some creative means, being BGP multihomed to some ISPs, connecting
club members with static IP subnets to this "club backbone".
Naturally, the club would like to document those assignments in
RIPE to provide sensible contact information for IP ranges, but
isn't allowed due to the "end user" style of PI assignments
(mnt-lower to RIPE NCC).

NCOs like clubs usually can't afford to become LIRs, but would
like to document such sub-assignments. I would suggest to treat
them like Cat C, but:

- Allocate a netblock of justified size, at least /21, like ISP LIRs
- Allow assignments within this allocation for documentation reasons
  (NOT usage level _justification_) in RIPE DB.
- require them to request their stuff via an established LIR like
  with Cat C and usualy PI requests today.
- no fees


Overall, in short:

A) normal LIR status, with normal LIR payments to RIPE NCC
B) end-user status, one-time fee plus moderate periodic maintenance fee
C) non-commercial (totally) end-user status, no fees, request via a LIR
D) non-commercial organisation able to document usage of IP blocks within
   their IP range, no fees, request via a LIR

So, Cat A+D would receive PA allocations, and Cat B+C would receive
PI assignments.

Reading all that again, I might overcomplicate things. But then again,
I don't simpler models being equally "fair". :-/

> Finally, it was noted that there is a requirement for globally
> unique addresses that will not be routed on the Internet.

This would fall under Cat B (if commercial) or Cat C (non-commercial).


Please take above as a proposal for discussion. I'm highly interested in
comments.


Best regards,
Daniel