FORMAL PROPOSAL: change of initial PA allocation size
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" 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 -- Total number of prefixes smaller than registry allocations: 57785 (56883) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
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@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================
Hi Sascha, On Fri, Oct 24, 2003 at 04:49:03PM +0200, Sascha Lenz wrote: [...]
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.
The proposal being discussed makes no change to the policy for PI assignments.
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 think that changes to the fee schedule can only be agreed by the General Meeting. [...]
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_
We publish a document detailing our minimum allocation and assignment sizes. The latest version can always be found at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Updates to the document are always announced on a number of mailing lists. If you can suggest a more appropriate set of lists to announce updates then we can update our procedure. Should this proposal be accepted we would not lower the minimum allocation size for any existing /8 to /21. The minimum would be applied to a new /8. This might be an appropriate place to remind people that the draft global policy for allocations from the IANA to RIRs is currently under review. The review period ends on 16 November. The document can be found at: <http://www.ripe.net/ripe/draft-documents/iana-rir-allocation-policies.html> Best regards, -- leo vegoda RIPE NCC Registration Services Manager
Hay, leo vegoda wrote: [...]
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.
The proposal being discussed makes no change to the policy for PI assignments.
right, that's why i wrote that this should be discussed seperately, probably by the time when someone raises the "no PI assignments anymore" policy suggestion again - which also was discussed at various ocassions. But the reasons given for the policy change suggested here are the first steps towards the scenario i described. "No more PI assigments" was always discussed together with the changes suggested here. Due to this circumstances i felt the urge to drop in here already so noone can say "most people in the RIPE community bark after they are hit only instead of joining the discussions early" again. Those annotations in the first paragraphs of my reply was only meant as a reminder for later discussion which i thought was clear enough. Sorry if this was misunderstood. Of course it's nothing directly affecting the change of the First-Allocation Policy...
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 think that changes to the fee schedule can only be agreed by the General Meeting.
[...]
No doubts about that. As i said, i didn't make any concrete suggestions. I just was a bit dissapointed that the newly introduced Extra-Small Membership is still ~2kEUR/year. But there are other possibilities to ensure that every organisation can get address space they want. There are PI assignments now, which i personally do like the way it is handled by RIPE right now. Though as mentioned above lowering the crieria for new LIRs and no need to show an initial use of a /22 is the first step towards shutting down PI assignments because noone (ISP, company..) would need PI space than anymore in first place. They just can get LIR now regardless of how small they are. Most seem to agree, that anyone who "own's" or manages address space should get a LIR in the future. I can only agree to this as long as the financal hurdle here is not set too high, otherwise i think we should keep going with PI/swamp assignments like now, at least for special circumstances.
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_
We publish a document detailing our minimum allocation and assignment sizes. The latest version can always be found at:
<http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html>
Updates to the document are always announced on a number of mailing lists. If you can suggest a more appropriate set of lists to announce updates then we can update our procedure.
Should this proposal be accepted we would not lower the minimum allocation size for any existing /8 to /21. The minimum would be applied to a new /8.
correct, every descent network operator does know the well known places where the RIRs do announce their minimum allocations ect. This just didn't help that often because there are also many not-so-decent network operators who only copy some bogon-filters from some book or article and never update them :-( Better ways of handling this are already being discussed on various other mailinglists, but with not very much consensus yet AFAICS. I can't help much about this, i'm no developer :-) I'd really suggest to start with /21 allocations from a new block and only use the old /8-blocks with their current minimum allocation size of /20 or /19 when a LIR requests Allocations of this size or bigger. In my eyes this would be the least painful and quickest way of introducing /21 Allocations. Anyways, to make it clear in the end: Please go for it! In general i certainly vote in favour for this policy change! -- ======================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ========================================================================
Dear WG, I would like to call for closure on this matter. As this has been presented and discussed at the last RIPE meeting and proposed to the list as a formal proposal I would like to declare consensus on this issue. There have been discussion on the mainlinglist with some critical comments that it is my understanding has been clearified. (This proposal does not affect the payment scedule or membership structure and it does not affecting the PI policy). With this I would normaly declare concensus but as no deadline was set for the discussion I propose a 1 week last call for objections to the process on this matter. If I receive objections I propose to set a I month comment period before calling for closure on this matter. Best Regards, Hans Petter Holen Address Policy WG Chair |-----Original Message----- |From: address-policy-wg-admin@ripe.net |[mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering |Sent: Friday, October 24, 2003 2:31 PM |To: address-policy-wg@ripe.net |Subject: [address-policy-wg] FORMAL PROPOSAL: change of |initial PA allocation size | |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" | | |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 |-- |Total number of prefixes smaller than registry allocations: |57785 (56883) | |SpaceNet AG Mail: netmaster@Space.Net |Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 |80807 Muenchen Fax : +49-89-32356-299 |
Dear WG, As I have seen no proposals to prolong this process, we have consensus on this matter. Seasons Greetings, Hans Petter Holen Address Policy WG Chair |Dear WG, |I would like to call for closure on this matter. As this has |been presented and discussed at the last RIPE meeting and |proposed to the list as a formal proposal I would like to |declare consensus on this issue. | |There have been discussion on the mainlinglist with some |critical comments that it is my understanding has been |clearified. (This proposal does not affect the payment scedule |or membership structure and it does not affecting the PI policy). | |With this I would normaly declare concensus but as no deadline |was set for the discussion I propose a 1 week last call for |objections to the process on this matter. If I receive |objections I propose to set a I month comment period before |calling for closure on this matter. | |Best Regards, |Hans Petter Holen |Address Policy WG Chair | ||-----Original Message----- ||From: address-policy-wg-admin@ripe.net ||[mailto:address-policy-wg-admin@ripe.net] On Behalf Of Gert Doering ||Sent: Friday, October 24, 2003 2:31 PM ||To: address-policy-wg@ripe.net ||Subject: [address-policy-wg] FORMAL PROPOSAL: change of initial PA ||allocation size || ||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" || || ||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 ||-- ||Total number of prefixes smaller than registry allocations: ||57785 (56883) || ||SpaceNet AG Mail: netmaster@Space.Net ||Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 ||80807 Muenchen Fax : +49-89-32356-299 || |
Date: Wednesday, 28 January 2004 Time: 09:00 - 12:30 Location: Grand Ballroomm Krasnapolsky Hotel, Amsterdam Webcast: This session will be webcast - http://www.ripe.net/ripe/meetings/webcast.html A. Administrative Matters - Select a Scribe - List of Participants - Agree Agenda - Approve minutes from RIPE 46 and RIPE 45: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2003/msg00176.html B. RIPE NCC Update (Leo Vegoda, RIPE NCC) C. ICANN ASO AC Update (TBD, ICANN ASO AC) D. Policy Development Process (TBD) E. AfriNIC: Status & Transition proposal (TBD) F. Charging by LIRs (TBD) G. RIRs' IPv6 Address Space requirements (Arno Meulenkamp, RIPE NCC) H. DENIC proposal for IPv4/IPv6 Anycast DNS Infrastructure Policy (Andreas Bäß, DENIC) I. Changing the 80% rule for IPv4 allocations (TBD) J. Review IPv6 policy (TBD) [...] Y. Open Mic. - Free to All Attendees Z. AOB
participants (4)
-
Gert Doering -
Hans Petter Holen -
leo vegoda -
Sascha Lenz