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

Hay,

On Thu, Aug 21, 2003 at 02:42:05AM +0200, Daniel Roesen wrote:
> 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 at ripe.net bounces as unknown), I guess
> further discussion should take place here (which makes some sense).

Closed, yes.

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

There shouldn't be much problems with that.

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

That was a bad one anyways, for the reasons mentioned already.

Such requirements only lead to faked requests and more work.
We even had a customer who insisted on us faking some PA assignments
for him so he can show a /22 for immediate use; of course he never 
wanted to use them
in first place since he didn't want to renumber his customers twice.
After we denied that, the customer left, but obviously found another
LIR who had no problems with such things, at least he is LIR now
for a while.

> > 3. No longer assign PI (Portable) address space to End Users
> 
> Strongly disagreed. Upstream-independent address space is _needed_.
> This cannot be ignored.

Oh my... the big PI vs. routing table size ect. discussion.
I _really_ don't want to get into this.

But in general, PI is needed - people, deal with it. 
(This goes for IPv6, too by the way... some day you all will notice).

> > 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. :-)

Hrnjaaa... Enterprise-LIRs are End-Users (more or less).

> 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.

ACK.
as always.

> 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).

basically, ACK.

I'm just no fan of being denied to enter useful information in
the database, if i want to. See below, in D)...
Why shouldn't it be allowed for big companies to use LIR-PARTITIONED
or hopefully soon sub-allocations ect?

...on the other hand, what company does keep their RIPE 
database objects up-to-date anyways? *bighsigh*

There's Enterprise-LIR status, i don't know how many
"big" companies get LIR and how many just request a PI-block though.

The problem is, you talk about NCOs not being able to document
their "sub-assignments" with PI space, but you deny even large
companies to do so with your suggestion here.
At least those big ones can get Enterprise-LIR up to now and 
then have the ability (and responsibility) to manage and document
their address space within their company, documenting different
contact persons, abuse addresses ect. per subsidiary and so on.

> 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.

Full-ACK. 
Since i'm personally involved in two (and a half) of this kind of
non-commercial organisations, i can only confirm this.

I'm not pleased with arguments like "you are small, you are not
commercial, you have no customers - why do you need to be in 
the global routing table? just get a descent IP uplink if you
want stable connectivity and a big ISP certainly doesn't go
bankrupt either so no need to renumber sometime soon!"-talk
one _always_ gets about this situation.

I'm absolutely against an Internet in the future, where only big
companies with much money and thousands of IP addresses are allowed
to be completely independant and have full backup connectivity.
(i.e., having their prefix(es) showing up in the DFZ).

NOT to assign anymore PI-space and denying a cheap way to get
PA Allocation blocks of routeable size for no/low fees 
would be a first step towards that.
NOT having some kind of PI-space in the IPv6 world is, too
(though, a bit different there, but that's another discussion).

> 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).

Thank you for describing what i constantly do because i'm forced to.
The housing subnets for club-members are refered as one big
"housing subnet" in the RIPE reuqest(s), but of course everyone
gets a small subnet and a VLAN ... but i can't document it, because
there's no sub-assigning or PI-Allocations (bad, bad...)
Same goes for IPSEC-Tunnels ect.

Though, the problem here seems to be that not enough of those
situations with NCOs exist?!
(if i'm wrong, show up people! :) )

==> Probably this shouldn't be narrowed down to NCOs, but also
    include "very small ISPs", who want to provide 
    adequate services but only have very few customers,
    and rather want to invest their money into infrastructure than
    in RIPE membership fees.
    Whatever, a local WLAN provider with some Hotspots and 
    few point2point links for some offices of customers with 
    permanent links ect.

Another point may be that many are not-so-unhappy about not
having the responsibility to deal with assignment and record-
keeping activities.
I'm not sure but i guess at least some NCOs/small ISPs are
quite happy with PI space for that reason, too.
(which is bad i mean if PI-space is abused for such reasons)

> 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

sounds like a nice compromise.
Another one would be an official introduction of PI-Allocations.
For example for me, in all cases i don't need a /21, a /23 is enough, most
likely forever. "ALLOCATED PI" status exists, why not use it?

Of course that's no solution for the future, if i read it right, available
PI-blocks are fading away fast. And with your suggestion, new requests
might result in PA-allocation-blocks of routable-size, no PI anymore.
But probably as additional feature for already existing situations
like that with existing PI-Assignments? -> migrate to PI-Allocations
on request?

...just an opinion since we already have many relatively small PI
blocks out there now which are probably used like described here
to a certain degree.

> 
> 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". :-/

I put it a bit more general

- Independant address space must be available for everone who has
  a good reason and knows what he/she is doing
  (that explicitiy does not mean "anyone" as in "anyone" :) )

- There should be possibilities to get address space and have
  the ability to assign address space without paying horrible
  RIPE membership fees and the need to fulfill minimum requirements
  if one is very small and/or a NCO
  Up to now, you can get PI-space from seperate PI-blocks, any
  size, but only assignments, no allocations, so documentation
  is impossible, this is bad for the reasons mentioned above.

  This was an intended situation, but i think it turned
  out badly. (More and more PI requests, no documentation
  of actual assignments within PI assignments...), so it 
  should be changed.

  And obviously PI-blocks are soon gone.

- Small(!) one time or per-year fees are OK, of course with 
  reduced RIPE services, or none at all (-> handling via a LIR);
  NO FEES are recommended for special cases like NCOs or veeery
  small ISPs

  Or to make it easier, probably some reduced-price LIR status 
  for those ("Status: Very Small < Small < Medium < Large" :) )
  It's most likely safe to assume that those "small" organisations
  who really want to get into all the RIPE stuff probably have 
  more self-interest in the things and mean less hassle than one
  or another "bigger" commercial LIR, so they don't really mean
  "more work" for the RIPE NCC.
  But that rather leads into the recent "RIPE-tasks and cost" 
  discussion we had earlier this month.

=> in short - Daniel's proposal is quite nice so far
   Though, I wouldn't refuse some kind of "enry-level LIR status" either.
   Sounds easier for me. Nothing new to implement (not much 
   at least) and no need for seperate PI blocks anymore..

> > 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).

I don't really see a difference about non-routed addresses either.

If IPv4 space finally runs out, probably some more developers and 
ISPs start deploying IPv6 faster, that's only positive.
Doesn't nescessarily mean to _waste_ IPv4 addresses, but i don't see
a point in more and more conservation policies.
(no more PI assignments... probably more restrictive policy for non-routed
addresses ect.)

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

done. Sorry for possible confusion, this is a pre-morning-coffee-reply.
I rather wonder why noone else replied yet?
Does that mean "granted" and we can implement that by next week? :)

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