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@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@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================