Criteria for initial PA Allocation
Dear all, At the last RIPE meeting (RIPE 39) in Bologna, the issue of criteria for PA Allocations was discussed in the LIR-WG. The presentation delivered is available from: http://www.ripe.net/meetings/archive/ripe-39/presentations/ (Please also refer to the mail sent out to the lir-working group the 25 April at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00056.html We would like the communities input on this matter. The problem brought up was the lack of clear and consistent policy on portable address space. Currently two types of portable address space are available: - Provider Aggregatable (PA) Allocations - Provider Independent (PI) Assignments The discussion was focused on criteria for PA Allocations as this is where the most significant policy inconsistency can be found. Current criteria for initial PA Allocations are: - Membership (You are required to be a member in order to get your first allocation. The RIPE NCC membership is open, anyone can become a member.) - Justification of first assignment (You are required to justify the first assignment you make out of your allocation. There is no minimum assignment size.) The minimal PA Allocation size is currently a /20 (= 4096 IP addresses) This means in reality that anyone who can justify one IP address is eligible for 4096 addresses. With an increased demand for independence and multi-homing, the RIPE NCC can see the consequences of this in the impressive membership growth in the last years: New LIRs set up per year: 1997: 262 1998: 446 1999: 525 2000: 865 2001: 997 (projected, end of year) The RIPE NCC has experienced several cases where organisations have insisted on becoming members in order to receive a portable /20 address block despite the fact they clearly state that their need is for less, in some cases only for c:a 300 addresses. We also observe organisations who become LIRs with the pure objective of obtaining portable address space but who are unaware of the responsibilities and workload membership comprises. As all assignments made are based on need, there is clearly a policy inconsistency in the fact that allocations currently do not require any such justification. Consensus was reached in the LIR-WG at RIPE 39 that a set of criteria should be defined for obtaining an initial PA Allocation. The working group also agreed that the exact details of those criteria should be further discussed on the mailing list. Extending the logic of basing address assignments on need and previous utilisation to allocations, I therefore put forward the following proposal: Proposed Initial PA Allocation Criteria: - Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?) - Agree to renumber (Required? Recommended?) As the need for portable address space is a complex matter, I would like to propose to first focus this discussion on defining these criteria. The matter clearly also touches on the matter of PI Assignments, which is something I would like to encourage further discussion on. However, I would like start by requesting the communities input on the matter of initial PA Allocation criteria. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ Relevant studies: ----------------- Philip Smith "Studies of the routing table": http://www.apnic.net/stats/bgp/ Geoff Huston "Measuring BGP": http://www.apnic.net/meetings/presentations/apricot01.ppt http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt Scott Marcus "ASN Growth": http://www.ripe.net/ripe/meetings/archive/ripe-38/index.html RIS report / BGP prefix distribution: http://www.ripe.net/ripencc/pub-services/np/ris-index.html
The RIPE NCC has experienced several cases where organisations have insisted on becoming members in order to receive a portable /20 address block despite the fact they clearly state that their need is for less, in some cases only for c:a 300 addresses. We also observe organisations who become LIRs with the pure objective of obtaining portable address space but who are unaware of the responsibilities and workload membership comprises.
We are painfully aware of this. Furthermore, many mid to large organisations could do it with less than a /24 as they are doing address translation and need only a handful of IPs for the translated users and a handful of public servers. However, I don't think it is feasible to allocate such small ranges. The only alternative to me seems to lower the initial allocation of Enterprise LIRs to a /22 or even a /24 (if a range is available that won't be filtered out by the usual prefix length policies), except if the LIR asks for something larger on the first request. By doing that, you would also be able to say to PI requesters to get a LIR, which they don't actually need to get their IPs as of now. Responsibilities - I honestly don't have a suggestion for that, other than pointing out that when one needs only one range and maybe a second one after many months or even years, this can probably be done without much hassle. It would be more of a problem if we were talking about ISPs, which need new allocations every day. -- Alfredo Sola Director técnico () ascii ribbon campaign /\ Support plain text e-mail
At 18:49 21/05/01 +0200, RIPE NCC Staff wrote:
Dear all,
At the last RIPE meeting (RIPE 39) in Bologna, the issue of criteria for PA Allocations was discussed in the LIR-WG. The presentation delivered is available from: http://www.ripe.net/meetings/archive/ripe-39/presentations/
(Please also refer to the mail sent out to the lir-working group the 25 April at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00056.html
We would like the communities input on this matter.
The problem brought up was the lack of clear and consistent policy on portable address space. Currently two types of portable address space are available: - Provider Aggregatable (PA) Allocations - Provider Independent (PI) Assignments
The discussion was focused on criteria for PA Allocations as this is where the most significant policy inconsistency can be found. Current criteria for initial PA Allocations are: - Membership (You are required to be a member in order to get your first allocation. The RIPE NCC membership is open, anyone can become a member.) - Justification of first assignment (You are required to justify the first assignment you make out of your allocation. There is no minimum assignment size.)
The minimal PA Allocation size is currently a /20 (= 4096 IP addresses) This means in reality that anyone who can justify one IP address is eligible for 4096 addresses.
With an increased demand for independence and multi-homing, the RIPE NCC can see the consequences of this in the impressive membership growth in the last years:
New LIRs set up per year: 1997: 262 1998: 446 1999: 525 2000: 865 2001: 997 (projected, end of year)
The RIPE NCC has experienced several cases where organisations have insisted on becoming members in order to receive a portable /20 address block despite the fact they clearly state that their need is for less, in some cases only for c:a 300 addresses. We also observe organisations who become LIRs with the pure objective of obtaining portable address space but who are unaware of the responsibilities and workload membership comprises.
As all assignments made are based on need, there is clearly a policy inconsistency in the fact that allocations currently do not require any such justification.
Consensus was reached in the LIR-WG at RIPE 39 that a set of criteria should be defined for obtaining an initial PA Allocation. The working group also agreed that the exact details of those criteria should be further discussed on the mailing list.
Extending the logic of basing address assignments on need and previous utilisation to allocations, I therefore put forward the following proposal:
Proposed Initial PA Allocation Criteria:
- Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?)
- Agree to renumber (Required? Recommended?)
As the need for portable address space is a complex matter, I would like to propose to first focus this discussion on defining these criteria.
You can view the criteria we have been using for the past 2 years at: http://www.isoc.org.il/ip-nets-rules.html You can see that we actively revoke allocations when an organization stops being multihomed: http://www.isoc.org.il/ipolicy.html Much more important than working out the details of what criteria qualify you for a /22 would be what criteria will cause RIPE to revoke the /22 it has assigned. -Hank
The matter clearly also touches on the matter of PI Assignments, which is something I would like to encourage further discussion on. However, I would like start by requesting the communities input on the matter of initial PA Allocation criteria.
Kind regards,
Nurani Nimpuno
+------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+
Relevant studies: ----------------- Philip Smith "Studies of the routing table": http://www.apnic.net/stats/bgp/ Geoff Huston "Measuring BGP": http://www.apnic.net/meetings/presentations/apricot01.ppt http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt Scott Marcus "ASN Growth": http://www.ripe.net/ripe/meetings/archive/ripe-38/index.html RIS report / BGP prefix distribution: http://www.ripe.net/ripencc/pub-services/np/ris-index.html
On Tue, 22 May 2001, Hank Nussbacher wrote: (...)
You can view the criteria we have been using for the past 2 years at: http://www.isoc.org.il/ip-nets-rules.html
You can see that we actively revoke allocations when an organization stops being multihomed: http://www.isoc.org.il/ipolicy.html
Much more important than working out the details of what criteria qualify you for a /22 would be what criteria will cause RIPE to revoke the /22 it has assigned.
100% support on this... "Cleaning-up" rules/processes would be a very good idea, because companies end their activity, or get bought by other companies, and in these cases a re-evaluation of the RIR's allocations could help save some "resources" :-) Portugal is perhaps not a great example by its reduced size, but what we are seeing here is that big ISPs are buying smaller ISPs, and smaller ISPs that cant get bought are on route to simply close doors... :-(
-Hank
Regards, ./Carlos "Networking is fun!" ------------------- <cfriacas@fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
| Much more important than working out the details of what criteria qualify | you for a /22 would be what criteria will cause RIPE to revoke the /22 it | has assigned. The proposal was that in order to qualify for a "standard /20 PA block" you would need to
- Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?)
- Agree to renumber (Required? Recommended?)
So the proposal is that in order to get a /20 you need to provide documentation that you need some percentage of that adress space (25%). As current policy states, the assignments you make from this allocation are only valid for as long as the criteria it was assigned under is stil valid. While I agree that it at some point would be interesting to discuss how to be more agressive reclaiming address space, I would urge the WG to focus on the proposal from RIPE NCC: - should we introduce a creiteria for PA allocations - if so what should that criteria be. -hph
Hi, seems I got carried away :-) On Tue, May 22, 2001 at 05:37:40PM +0200, Hans Petter Holen wrote:
| Much more important than working out the details of what criteria qualify | you for a /22 would be what criteria will cause RIPE to revoke the /22 it | has assigned.
The proposal was that in order to qualify for a "standard /20 PA block" you would need to
- Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?)
- Agree to renumber (Required? Recommended?)
So the proposal is that in order to get a /20 you need to provide documentation that you need some percentage of that adress space (25%).
This is similar to the ARIN policy. I think it makes sense - if you are not able to fill a /22, your network is "smallish". So using PA space and renumbering when changing ISPs is not *that* hard, if done properly (DHCP, DNS, no hard-coded IP addresses anywhere). If you're actually doing LIR work (that is: hand out addresses to third parties), documenting this should also be possible.
While I agree that it at some point would be interesting to discuss how to be more agressive reclaiming address space, I would urge the WG to focus on the proposal from RIPE NCC: - should we introduce a creiteria for PA allocations - if so what should that criteria be.
I'm not so sure on the "should we", but if yes, the above criteria are a good thing. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <20010522213112.H17832@Space.Net>, Gert Doering writes:
Hi,
seems I got carried away :-)
On Tue, May 22, 2001 at 05:37:40PM +0200, Hans Petter Holen wrote:
| Much more important than working out the details of what criteria qualify | you for a /22 would be what criteria will cause RIPE to revoke the /22 it | has assigned.
The proposal was that in order to qualify for a "standard /20 PA block" you would need to
- Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?)
- Agree to renumber (Required? Recommended?)
So the proposal is that in order to get a /20 you need to provide documentation that you need some percentage of that adress space (25%).
This is similar to the ARIN policy.
I think it makes sense - if you are not able to fill a /22, your network is "smallish". So using PA space and renumbering when changing ISPs is not *that* hard, if done properly (DHCP, DNS, no hard-coded IP addresses anywhere).
I know several companies who would be willing to renumber once per year as long as they can be multihomed... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
| >I think it makes sense - if you are not able to fill a /22, your network | >is "smallish". So using PA space and renumbering when changing ISPs is | >not *that* hard, if done properly (DHCP, DNS, no hard-coded IP addresses | >anywhere). | | I know several companies who would be willing to renumber once per year | as long as they can be multihomed... Why should I have to renumber once a year to be multi-homed ? -hph
In message <002101c0e301$8b591f00$0600000a@hph>, "Hans Petter Holen" writes:
| >I think it makes sense - if you are not able to fill a /22, your network | >is "smallish". So using PA space and renumbering when changing ISPs is | >not *that* hard, if done properly (DHCP, DNS, no hard-coded IP addresses | >anywhere). | | I know several companies who would be willing to renumber once per year | as long as they can be multihomed...
Why should I have to renumber once a year to be multi-homed ?
I'm not saying you should, I'm saying people are willing to it. To me that indicates that we are not looking at the problem right now, but on a symptom of the >real< problem. I think the solution to the real problem is to find a better method for assignment of routable IPs to multihomed customers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
While I agree that it at some point would be interesting to discuss how to be more agressive reclaiming address space, I would urge the WG to focus on the proposal from RIPE NCC: - should we introduce a creiteria for PA allocations - if so what should that criteria be.
RFC 2050 clearly outlines one of the primary responsibilities of the RIRs: conservation. Though this responsibility often does not reconcile with another primary responsibility, the stability of the routing infrastructure, it is nonetheless an important concept. RIPE's long-standing tradition of handing out /19s and /20s to all requestors, *regardless of actual need*, clearly irresponsibly violates the essential tenants of RFC 2050 - a document which is supposed to be the foundation of an RIR's address assignment policies. I implore the RIPE LIR-WG to support the NCC's current effort to better focus the PA and PI allocation guidelines on the principles so enumerated in RFC 2050. The current discussion in this thread, while interesting, does not appear to give sufficient feedback to the NCC staff trying to gauge consensus (or lack thereof). Thus, I urge you to reply to these messages with your professional opinions: (1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible? (2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)? (3) Do you agree or disagree that RIPE should implement a PI assignment policy establishing an assignment model consistent with the principles established for such assignments in RFC 2050 (25% utilization immediately, 50% utilization within one year)? [BTW, the NCC hasn't proposed (3). I'm just throwing it out there.] (4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE? /david
I need to put my own thoughts forward, too :>
(1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible?
Yes. It's enormously wasteful of a scarce resource and is one factor among many encouraging the RIPE NCC wait queue to be unacceptably long.
(2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)?
YES! The RIPE community is sufficiently advanced that imposing a minimum existence on requestors should not be a burden to significant regional economic development. I believe the minimum utilization size should be a /21, not a /22 as intimated by one member of the NCC staff. Organizations requesting a /20 from RIPE should be held to the *same guidelines* as everyone else as outlined in RFC 2050 - slow-start. If REQUESTOR A is efficiently utilizing a /21, they are certainly entitled, in the slow-start model, to request a /20 for their upcoming growth. But if REQUESTOR B is utilizing a /22, they are only entitled to a /21, not a /20. A /22 is too insignificantly sized to gauge the justification for a full /20. A /21 is one exponential factor greater - a statistically relevant distinction.
(3) Do you agree or disagree that RIPE should implement a PI assignment policy establishing an assignment model consistent with the principles established for such assignments in RFC 2050 (25% utilization immediately, 50% utilization within one year)?
Since I'm the one who is proposing it, ayep. It has been said here by many people that PI assignments should only be for exactly what an organization needs. I contend that an organization should be given some flexibility in regards to future growth.
(4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE?
No. I think this is a fundamental flaw in the ARIN community's interpretations of RFC 2050 - it too heavily relies on the conservation principle and too easily discounts operational effects of such a policy. If ISP A is using a /21 from an upstream, and is able to justify a /20 from RIPE, the ISP should be entrusted to do what it wishes with the original /21 - return it, renumber it, keep it. The conservation principle is insignificantly served by forcing renumbering of /22s or /21s, in my opinion. Also, the administrative overhead of *enforcing* such a policy outweighs the benefit of the policy, in my opinion. It will encourage the wait queue to lengthen, not contract. /david
(2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)?
I agree that there should be a policy and that it should be a minimum of a /21.
(3) Do you agree or disagree that RIPE should implement a PI assignment policy establishing an assignment model consistent with the principles established for such assignments in RFC 2050 (25% utilization immediately, 50% utilization within one year)?
If RIPE is going to continue to assign PI space, then yes a policy should be established. We also need to consider what PI assignments are doing to the routing tables and whether there should be a minimum PI assignment size or whether RIPE should continue making PI assignments at all.
(4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE?
I agree with David's opinion in regards to this question. If the organization has justified the address space from RIPE, then they should be able to decide what to do with their current Address space from their upstream provider. Tanya -----Original Message----- From: owner-lir-wg@ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of David R Huberman Sent: Wednesday, May 23, 2001 2:05 PM To: Hans Petter Holen Cc: lir-wg@ripe.net Subject: Re: Criteria for initial PA Allocation I need to put my own thoughts forward, too :>
(1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible?
Yes. It's enormously wasteful of a scarce resource and is one factor among many encouraging the RIPE NCC wait queue to be unacceptably long.
(2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)?
YES! The RIPE community is sufficiently advanced that imposing a minimum existence on requestors should not be a burden to significant regional economic development. I believe the minimum utilization size should be a /21, not a /22 as intimated by one member of the NCC staff. Organizations requesting a /20 from RIPE should be held to the *same guidelines* as everyone else as outlined in RFC 2050 - slow-start. If REQUESTOR A is efficiently utilizing a /21, they are certainly entitled, in the slow-start model, to request a /20 for their upcoming growth. But if REQUESTOR B is utilizing a /22, they are only entitled to a /21, not a /20. A /22 is too insignificantly sized to gauge the justification for a full /20. A /21 is one exponential factor greater - a statistically relevant distinction.
(3) Do you agree or disagree that RIPE should implement a PI assignment policy establishing an assignment model consistent with the principles established for such assignments in RFC 2050 (25% utilization immediately, 50% utilization within one year)?
Since I'm the one who is proposing it, ayep. It has been said here by many people that PI assignments should only be for exactly what an organization needs. I contend that an organization should be given some flexibility in regards to future growth.
(4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE?
No. I think this is a fundamental flaw in the ARIN community's interpretations of RFC 2050 - it too heavily relies on the conservation principle and too easily discounts operational effects of such a policy. If ISP A is using a /21 from an upstream, and is able to justify a /20 from RIPE, the ISP should be entrusted to do what it wishes with the original /21 - return it, renumber it, keep it. The conservation principle is insignificantly served by forcing renumbering of /22s or /21s, in my opinion. Also, the administrative overhead of *enforcing* such a policy outweighs the benefit of the policy, in my opinion. It will encourage the wait queue to lengthen, not contract. /david
Hi, On Wed, May 23, 2001 at 10:52:24AM -0700, David R Huberman wrote:
RIPE's long-standing tradition of handing out /19s and /20s to all requestors, *regardless of actual need*, clearly irresponsibly violates the essential tenants of RFC 2050 - a document which is supposed to be the foundation of an RIR's address assignment policies.
As the original intention was to hand out such space to *registries*, who would then go on to hand out this space to their customers, and eventually come back to get *more* address space, your paragraph simply isn't true (and calling RIPE "irresponsible" is hardly fair). The fact that an increasing number of applicants do not come back to ask for more space has lead to the change from an initial /19 to /20 last year - which was NOT something that the community took lightly, there was quite some discussion.
(1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible?
I disagree. The RIRs have to balance conservation and aggregation. /20 is a good compromise. Some addresses might be wasted, but so what. Routing stability and routing table size is a bigger problem than address wastage, and lowering initial assignments will lead to more fragmentation and thus to larger routing tables.
(2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)?
Yes. Because this keeps the number of entries in the global table to those that have a sufficient large number of "host-things", and there are fewer of those.
(3) Do you agree or disagree that RIPE should implement a PI assignment policy establishing an assignment model consistent with the principles established for such assignments in RFC 2050 (25% utilization immediately, 50% utilization within one year)?
[BTW, the NCC hasn't proposed (3). I'm just throwing it out there.]
This is done anyway, as far as I remember - whatever RIPE-141 (++) you send in, it has to show 25/50% utilization (it does not have to be "one year", but "the period that you can plan for").
(4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE?
Yes. If they have a larger space, they should move their stuff into the new /20 (or whatever), and stop announcing the old network. In the typical case (the /20 might not be filled ever, and the original space might fit in there just fine) this is good for aggregation *and* conservation. It's just inconvenient, but so is filling in RIPE-141's instead of giving everybody a Class B. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
As the original intention was to hand out such space to *registries*, who would then go on to hand out this space to their customers, and eventually come back to get *more* address space, your paragraph simply isn't true (and calling RIPE "irresponsible" is hardly fair).
Point taken. My wording was from a modern implementation of the policy perspective.
(1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible?
I disagree. The RIRs have to balance conservation and aggregation.
/20 is a good compromise. Some addresses might be wasted, but so what.
Routing stability and routing table size is a bigger problem than address wastage, and lowering initial assignments will lead to more fragmentation and thus to larger routing tables.
Please don't put me in the same bucket as those talking about *lowering* the minimum allocation size. This question was simply a preface to (2) below - requiring a indefinite amount of existing address space utilization before qualifying for a RIPE block. Please - the point I was trying to make was the someone who needs a /29 should not be getting a /20 and becoming an LIR simply because they can afford the 2000 Euros.
(2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)?
Yes. Because this keeps the number of entries in the global table to those that have a sufficient large number of "host-things", and there are fewer of those.
Gert, how much address space should an organization have to demonstrate efficient utilization of before being able to qualify for a PA /20 in your opinion?
(4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE?
Yes. If they have a larger space, they should move their stuff into the new /20 (or whatever), and stop announcing the old network.
You're making the assumption they're announcing the route(s) separately from their upstream's aggregate. I don't want to make such assumptions. If the group feels that we should make distinctions between multi-homed requestors and single-homed requestors, that's a discussion we need to have. I feel that in the case of an organization assigned upstream space from one provider, renumbering shouldn't be forced on them. (a) it doesnt help the routing tables in this case; (b) it's a huge burden on the NCC wait queue, in my estimation. (NCC? Comments?) /david
Hi, On Wed, May 23, 2001 at 02:45:19PM -0700, David R Huberman wrote:
(1) Do you agree or disagree that allocating /20s to every requestor who can justify an initial assignment is irresponsible?
I disagree. The RIRs have to balance conservation and aggregation. [..] Please don't put me in the same bucket as those talking about *lowering* the minimum allocation size.
Sounds I misunderstood your point (it following the "irresponsibility" claim it could be read as "initial size should be a /26" :-) ). [..]
(2) Do you agree or disagree that RIPE should consider establishing a policy by which an organization can only request a PA allocation if it can demonstrate the efficient utilization of an existing block of IP address space (as yet undefined - /22, /21, /20, etc.)?
Yes. Because this keeps the number of entries in the global table to those that have a sufficient large number of "host-things", and there are fewer of those.
Gert, how much address space should an organization have to demonstrate efficient utilization of before being able to qualify for a PA /20 in your opinion?
I'm not sure. I feel that a /22 is a good value - it means "25% of the /20", and is large enough (4 "class C") that people need to get a feel for network planning, subnet structure and whatnot. But I don't have any hard feelings on this, maybe a /21 is better ("raise the hurdle") or a /23 ("we should not be overly restrictive").
(4) Should organizations which are using a relatively small amount of address space be required to renumber in order to recieve a PA allocation from RIPE?
Yes. If they have a larger space, they should move their stuff into the new /20 (or whatever), and stop announcing the old network.
You're making the assumption they're announcing the route(s) separately from their upstream's aggregate.
Hmmm, yes. But otherwise, what good would it be to get their own address space if they are not going to multi-home it -- and on the other hand, *if* they are going to multi-home, what good would it do them to hold address space that they can only use single-homed?
I don't want to make such assumptions.
If the group feels that we should make distinctions between multi-homed requestors and single-homed requestors, that's a discussion we need to have.
Maybe, yes. But then, I haven't yet met anyone that went LIR in the last years that did *not* do it to get "address space they could announce to whoever they like", which usually also meant "going multi-homed sooner or later". But this is only Germany :-)
I feel that in the case of an organization assigned upstream space from one provider, renumbering shouldn't be forced on them. (a) it doesnt help the routing tables in this case; (b) it's a huge burden on the NCC wait queue, in my estimation. (NCC? Comments?)
I don't think it will hit the wait queue, but it *will* increase the effort required at audit time. Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hiya all, On Wed, 23 May 2001, David R Huberman wrote: ->If the group feels that we should make distinctions between multi-homed ->requestors and single-homed requestors, that's a discussion we need to ->have. I do not understand where this perspective comes from. Singlehomed users should use PA address space. But see below... As Gert has said, and probably RIPE can confirm, we think nearly all requests are with the intention of multihoming. However, there are also "zero-homed" requesters: folks who require addresses that need to be globally unique but that will never appear in the global routing table. An example would be a management network for VPN services (the VPN users have the right to use all private IP addresses). Extranets might be another example. Whatever conclusions we arrive at, we should not prevent small appropriately sized PI assignments to these folks (I would probably support the withdrawing of future PI assignments to folks who intend to multihome - and replace them with a uniform PA Allocation policy). Cheers Dave
Hi, On Fri, May 25, 2001 at 02:05:52PM +0200, Dave Pratt wrote:
Whatever conclusions we arrive at, we should not prevent small appropriately sized PI assignments to these folks (I would probably support the withdrawing of future PI assignments to folks who intend to multihome - and replace them with a uniform PA Allocation policy).
I agree, but that's even more tricky to specify as a policy... Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
At the last RIPE meeting (RIPE 39) in Bologna, the issue of criteria for PA Allocations was discussed in the LIR-WG. The presentation delivered is available from: http://www.ripe.net/meetings/archive/ripe-39/presentations/
A couple of comments to the slide "reasons for portable address size (#7): - we want our own routable block yes, sure. What is the entity who can guarantee this. The RIR's? For reasons such us technical limitations and the overall wellbeeing of the existing community doing full routing, there has to be some limitations, best practises and guidelines. If an applicant is granted an address space using this argument as a reason, who wants to carry (s)he's routes anyway? So you want your own block, but I do not want to route it, we have a problem or not? - we want to use BGP and be multi-homed Good. There exists several methods you could run a working network also with this approach, even when you get address space from your upstream providers. Alternatives include NAT, private-ASN and address space from upstream, unique-ASN and private addr. space, unique-ASN and address space from upstream. You can also make use of the "do-not-export" and "do-not-advertise" attributes to make things work. One problem still remains with this; if you want to peer with multiple providers at some public IX. Then it is unlikely that you can play around with these options. I do suppose that majority of IX peers are LIR's anyhow and this maybe isn't a real problem afterall. - we need to be independed In Internet community at large we are all depended from each other. If you do not like your current providers, make a change or became one of yourself. I really do not think that beeing independed at Internet has anything to do with numbers (numbers are just a technical way of doing things, like E.164 telephony numbers). - our upstream adviced use to become a LIR Well, if you are acting like a LIR (= assigning address space further to your partners/customers etc), then maybe you should. There is some extra work in sight that has to be taken into account when making this decision. But if you don't feel like a LIR, or do not want to run LIR procedures, then you should not be forced to be one.
With an increased demand for independence and multi-homing, the RIPE NCC can see the consequences of this in the impressive membership growth in the last years: --clip-- The RIPE NCC has experienced several cases where organisations have insisted on becoming members in order to receive a portable /20 address block despite the fact they clearly state that their need is for less, in some cases only for c:a 300 addresses. We also observe organisations who become LIRs with the pure objective of obtaining portable address space but who are unaware of the responsibilities and workload membership comprises.
Are all members counted as LIR's? My opinion is that members assigning address space further down to other organisations should be counted as LIR's. Others are just members. LIR's then get initial allocations, others do not. If a member claims to be a LIR, but haven't made further assignments within a reasonable time, the member status could be revised. Problem is then what happens to the address space the member holds? Maybe a renumbering is needed (something that all PA address space holders have agreed anyhow, if necessary).
As all assignments made are based on need, there is clearly a policy inconsistency in the fact that allocations currently do not require any such justification.
If allocations are only granted to LIR's then I see no problem with this. If allocations are granted to everybody we clearly have a non-scalable situation here.
Extending the logic of basing address assignments on need and previous utilisation to allocations, I therefore put forward the following proposal:
Proposed Initial PA Allocation Criteria:
- Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?)
- Agree to renumber (Required? Recommended?)
Hhmm. What if we just open up the restrictions having assignments from more than one upstream (LIR). If multihomed (with unique-ASN or private-ASN), the user could hold similar assignments from each upstream provider. This means that the organisation is required to fullfill address requirements only once. The scaling of this is also questionable, but it makes possible to have larger aggregations. This seems to be the point here anyhow, to reduce the growth of the routing table.
The matter clearly also touches on the matter of PI Assignments, which is something I would like to encourage further discussion on. However, I would like start by requesting the communities input on the matter of initial PA Allocation criteria.
PI assignments should be limited exactly to the amount what is needed. If the amount needed is not large enough to be routable the applicant should re-think it's strategy. In my opinion RIR's have no responsibilities towards the community what is the minimum routable aggregation size. Jorma ---------------------------------- jorma.mellin@teliafi.net Development Manager ; CCIE#4185 Telia Finland Inc, Carrier&Networks
On Mon, 21 May 2001, RIPE NCC Staff wrote:
Dear all,
At the last RIPE meeting (RIPE 39) in Bologna, the issue of criteria for PA Allocations was discussed in the LIR-WG. The presentation delivered is available from: http://www.ripe.net/meetings/archive/ripe-39/presentations/
(Please also refer to the mail sent out to the lir-working group the 25 April at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00056.html
We would like the communities input on this matter.
The problem brought up was the lack of clear and consistent policy on portable address space. Currently two types of portable address space are available: - Provider Aggregatable (PA) Allocations - Provider Independent (PI) Assignments
The discussion was focused on criteria for PA Allocations as this is where the most significant policy inconsistency can be found. Current criteria for initial PA Allocations are: - Membership (You are required to be a member in order to get your first allocation. The RIPE NCC membership is open, anyone can become a member.) - Justification of first assignment (You are required to justify the first assignment you make out of your allocation. There is no minimum assignment size.)
The minimal PA Allocation size is currently a /20 (= 4096 IP addresses) This means in reality that anyone who can justify one IP address is eligible for 4096 addresses.
Hello. /22 is a much more reasonable value by my view... what percentage of members are ISPs ? :-) Perhaps its possible to typify in some way the organizations that actually do the requests, and start using different minimum PA allocation sizes. For instance... an ISP could get the minimal PA allocation of /20 the same way, but a bank or an insurance company, that normally represents a client for an ISP, could have a different minimal (and shorter!) PA allocation.
With an increased demand for independence and multi-homing, the RIPE NCC can see the consequences of this in the impressive membership growth in the last years:
New LIRs set up per year: 1997: 262 1998: 446 1999: 525 2000: 865 2001: 997 (projected, end of year)
The RIPE NCC has experienced several cases where organisations have insisted on becoming members in order to receive a portable /20 address block despite the fact they clearly state that their need is for less, in some cases only for c:a 300 addresses. We also observe organisations who become LIRs with the pure objective of obtaining portable address space but who are unaware of the responsibilities and workload membership comprises.
Imposing a minimum number of *active* peers (and within a specified time) should help to reduce these cases...
As all assignments made are based on need,
Sometimes on a "pseudo-need", i think... :-)
there is clearly a policy inconsistency in the fact that allocations currently do not require any such justification.
Only first allocs, or second/third/... too ?
Consensus was reached in the LIR-WG at RIPE 39 that a set of criteria should be defined for obtaining an initial PA Allocation. The working group also agreed that the exact details of those criteria should be further discussed on the mailing list.
Extending the logic of basing address assignments on need and previous utilisation to allocations, I therefore put forward the following proposal:
Proposed Initial PA Allocation Criteria:
- Demonstrated efficient utilisation of a /xx (/22?) Or - Immediate need for a /xx (/22?)
- Agree to renumber (Required? Recommended?)
Requirement should only be mandatory with well defined boundaries... - Need to renumber with X "disjoint" allocations - And depending on the size of the allocation... renumbering a /20 i think its not impossible, but i dont see anyone starting to renumber a /16 or a bigger one...
As the need for portable address space is a complex matter, I would like to propose to first focus this discussion on defining these criteria.
The matter clearly also touches on the matter of PI Assignments, which is something I would like to encourage further discussion on. However, I would like start by requesting the communities input on the matter of initial PA Allocation criteria.
Normally when an ISP client gets a /20 directly it requests also an ASN, right ? If they would only get some PI space, wouldnt we save some more ASNs ? (...) I have a question about this... isnt there a way of enforcing organizations that only have one peering to give back "their" "misused" ASN to the RIR ? Does anyone know a tool that uses RIPE DBs and that can do these kind of verifications quickly ? :-)
Kind regards,
Nurani Nimpuno
Regards, ./Carlos "Networking is fun!" ------------------- <cfriacas@fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
Hi, (originally I did not really want to participate in this discussion, as much of it has already been said in the last LIR-WG meeting). One thing got me thinking,though: On Tue, May 22, 2001 at 02:16:32PM +0100, Carlos Friacas wrote:
/22 is a much more reasonable value by my view...
Be careful what you are asking for. If we assume that minimum allocation size will go down to a /22, and further assume that one fourth of the full IPv4 address range will subsequently be handed out *and announced* as /22's, this means we will see ( 1/4 * 2^22 ) = 1048576 /22's announced in the global BGP table. That's over a million BGP routing table entries. This will have a significant effect on BGP routing stability and also on the costs of global routing - you need a Gig of RAM in all the BGP routers (on distributed architectures, more than that). The CPU power required to handle a flap of a major line in a timely fashion (to keep BGP convergence times low) will be horrendous. Also, it can be assumed that in this case, the global topology will become complex enough so that most of the time many of the smaller ASes won't be reachable anyway due to problems "on the way". I think this is something I do NOT want to see. So, what is my conclusion? I estimate that while IPv4 address exhaustion is going to be a problem (which IPv6 will solve), the routing topology will cause major problems *sooner* than IPv4 runs out, and we should do something against this. By this, I mean: - strongly encourage people to renumber from historic PI space to PA space from their ISPs network block (and return the PI space to the RIRs, to be aggregated) - stop handing out PI space - discourage "end users" from using multihoming with globally visible address space (there are other ways, like "get multiple uplinks to different POPs of the same ISP, and have them sign a SLA that will get you 99.9% reachability or money back"). - discourage people from becoming LIR if that's only to get "portable" address space, with no intention of handing PA space out to customers. Yes, this might sound a bit harsh, but I'm *really* worried about routeability and reachability of anything in the next couple of years. Now go and flame me... :-) Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hiya all, I agree completely with Gert. Not everyone can have a globally routable address block just so they can be multihomed. At the very least we need considerable obstacles to prevent everyone from trying to achieve this. Either we must charge $ for this benefit (I dislike this option too), or we must make rules to prevent excessive growth in the routing table, or we can do as we have so far (make the process so complex that folks give up before they succeed !!!). The problem I see is agreeing on the rules to prevent excessive growth. Just deciding what is excessive growth is hard enough. When these rules are determined, in my view they also need applying identically to the IPv6 address space. Cheers Dave On Tue, 22 May 2001, Gert Doering, Netmaster wrote: ->Hi, -> ->(originally I did not really want to participate in this discussion, ->as much of it has already been said in the last LIR-WG meeting). -> ->One thing got me thinking,though: -> ->On Tue, May 22, 2001 at 02:16:32PM +0100, Carlos Friacas wrote: ->> /22 is a much more reasonable value by my view... -> ->Be careful what you are asking for. -> ->If we assume that minimum allocation size will go down to a /22, and ->further assume that one fourth of the full IPv4 address range will ->subsequently be handed out *and announced* as /22's, this means we ->will see ( 1/4 * 2^22 ) = 1048576 /22's announced in the global BGP ->table. That's over a million BGP routing table entries. -> ->This will have a significant effect on BGP routing stability and ->also on the costs of global routing - you need a Gig of RAM in all ->the BGP routers (on distributed architectures, more than that). The ->CPU power required to handle a flap of a major line in a timely fashion ->(to keep BGP convergence times low) will be horrendous. -> ->Also, it can be assumed that in this case, the global topology will ->become complex enough so that most of the time many of the smaller ->ASes won't be reachable anyway due to problems "on the way". -> ->I think this is something I do NOT want to see. -> -> ->So, what is my conclusion? I estimate that while IPv4 address exhaustion ->is going to be a problem (which IPv6 will solve), the routing topology ->will cause major problems *sooner* than IPv4 runs out, and we should ->do something against this. By this, I mean: -> -> - strongly encourage people to renumber from historic PI space to -> PA space from their ISPs network block (and return the PI space -> to the RIRs, to be aggregated) -> -> - stop handing out PI space -> -> - discourage "end users" from using multihoming with globally visible -> address space (there are other ways, like "get multiple uplinks -> to different POPs of the same ISP, and have them sign a SLA that -> will get you 99.9% reachability or money back"). -> -> - discourage people from becoming LIR if that's only to get "portable" -> address space, with no intention of handing PA space out to customers. -> ->Yes, this might sound a bit harsh, but I'm *really* worried about ->routeability and reachability of anything in the next couple of years. -> ->Now go and flame me... :-) -> ->Gert Doering -> -- NetMaster ->-- ->SpaceNet AG Mail: netmaster@Space.Net ->Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 ->80807 Muenchen Fax : +49-89-32356-299 -> -> ->
On Tue, 22 May 2001, Dave Pratt wrote:
Hiya all,
I agree completely with Gert.
Not everyone can have a globally routable address block just so they can be multihomed.
At the very least we need considerable obstacles to prevent everyone from trying to achieve this.
Either we must charge $ for this benefit (I dislike this option too), or we must make rules to prevent excessive growth in the routing table, or we can do as we have so far (make the process so complex that folks give up before they succeed !!!).
I think this is an excellent idea... number of peers could be a criteria, but we would have to keep in mind some countries dimensions... Here, having 20 peers is very good, but i think in .de or in .uk, that number would indicate a "small AS", no ? This # of peers criteria would also give entities already with an ASN some "control" about new ASNs... perhaps this would be against any anti-trust law...
The problem I see is agreeing on the rules to prevent excessive growth. Just deciding what is excessive growth is hard enough.
Yes, as i was saying... different countries, different dimensions... but what we have seen here is that the market tends to regulate itself... some ISPs will probably disappear or will be bought by bigger ones.
When these rules are determined, in my view they also need applying identically to the IPv6 address space.
Sure. Doing otherwise would be a great mistake... i remember someone once said... "640kb will be much more than we will ever need!" ;-)
Cheers Dave
Regards, ./Carlos "Networking is fun!" ------------------- <cfriacas@fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
In message <Pine.BSF.4.21.0105222115270.16621-100000@atlas.rccn.net>, Carlos Friacas <cfriacas@fccn.pt> writes
i remember someone once said... "640kb will be much more than we will ever need!" ;-)
It was, of course, a weak justification of an earlier address space exhaustion: splitting the 1MByte address space of a 16bit cpu into 16 "slots" of 64K, 10 for RAM and 6 for ROM/Peripherals. With hindsight 12/4 might have been a better choice - the moral being it was unfortunate that the split was inflexible. -- Roland Perry
On Tue, 22 May 2001, Gert Doering, Netmaster wrote:
Hi,
(originally I did not really want to participate in this discussion, as much of it has already been said in the last LIR-WG meeting).
One thing got me thinking,though:
On Tue, May 22, 2001 at 02:16:32PM +0100, Carlos Friacas wrote:
/22 is a much more reasonable value by my view...
Be careful what you are asking for.
By lowering the "minimum" PA allocation for "non-ISPs" i wasnt thinking about getting more fragmentation... I was seeing that "minimum" <> "initial" too...
If we assume that minimum allocation size will go down to a /22, and further assume that one fourth of the full IPv4 address range will subsequently be handed out *and announced* as /22's, this means we will see ( 1/4 * 2^22 ) = 1048576 /22's announced in the global BGP table. That's over a million BGP routing table entries.
This will have a significant effect on BGP routing stability and also on the costs of global routing - you need a Gig of RAM in all the BGP routers (on distributed architectures, more than that). The CPU power required to handle a flap of a major line in a timely fashion (to keep BGP convergence times low) will be horrendous.
100% agree... i dont like to see it get much more bigger...
Also, it can be assumed that in this case, the global topology will become complex enough so that most of the time many of the smaller ASes won't be reachable anyway due to problems "on the way".
I think this is something I do NOT want to see.
So, what is my conclusion? I estimate that while IPv4 address exhaustion is going to be a problem (which IPv6 will solve), the routing topology will cause major problems *sooner* than IPv4 runs out, and we should do something against this. By this, I mean:
- strongly encourage people to renumber from historic PI space to PA space from their ISPs network block (and return the PI space to the RIRs, to be aggregated)
:-) the finest way would be turning it "mandatory"... i know this problem very well, as i've already done too much work recovering some 192.x.x.x still given by ARIN... :-) I still didnt finish this on my clients because some of them see it as a "RESOURCE", and some are trying to X*Y valid addrissing by only returning X address space... :-(
- stop handing out PI space
:-) well... could RIPE just talk to registered ISPs...? I think this is very, very hard thing...
- discourage "end users" from using multihoming with globally visible address space (there are other ways, like "get multiple uplinks to different POPs of the same ISP, and have them sign a SLA that will get you 99.9% reachability or money back").
this brings one question... is this way cheaper or not ? i've heard of some cases that a "end user" who is also a LIR got his address space "divided" (originated) between two ISPs and on the inside they somehow manage the situation... but this doesnt guarantee redundancy to their full address space, of course...
- discourage people from becoming LIR if that's only to get "portable" address space, with no intention of handing PA space out to customers.
no customers = no ISP ?
Yes, this might sound a bit harsh, but I'm *really* worried about routeability and reachability of anything in the next couple of years.
Yep... i see more than 104.000...
Now go and flame me... :-)
That's not the intention of it.
Gert Doering -- NetMaster -- SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
./Carlos "Networking is fun!" ------------------- <cfriacas@fccn.pt>, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
| Hello. | | /22 is a much more reasonable value by my view... what percentage of | members are ISPs ? :-) | Perhaps its possible to typify in some way the organizations that actually | do the requests, and start using different minimum PA allocation sizes. | For instance... an ISP could get the minimal PA allocation of /20 the same | way, but a bank or an insurance company, that normally represents a client | for an ISP, could have a different minimal (and shorter!) PA allocation. The purpose of this proposal was to make it more difficult for small organisations to become a separate LIR in order to reduce the workload on the RIPE NCC. It will be a good ting for address space conservation, and it will be a got thing for routing table size to "force" more organisations to go to one of their upstream providers. I do not think it is a good idea to make a smaller initial allocation size. -hph
On Mon, May 21, 2001 at 06:49:24PM +0200, RIPE NCC Staff wrote:
Dear all, [..skipped..] With an increased demand for independence and multi-homing, the RIPE NCC can see the consequences of this in the impressive membership growth in the last years:
New LIRs set up per year: 1997: 262 1998: 446 1999: 525 2000: 865 2001: 997 (projected, end of year)
Do you have similar statistics about PI assignments per year? -- Regards, Vladimir.
Dear Vladimir, My whole presentation "Developing clear and realistic policy on Portable Address Space" can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-39/index.html In there I am presenting the following statistics on PI requests: 1998: 179 1999: 316 2000: 608 Cheers Nurani -- +------------------------------------+ | Nurani Nimpuno | | Registration Services Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ "Vladimir A. Jakovenko" <vovik@lucky.net> writes: * On Mon, May 21, 2001 at 06:49:24PM +0200, RIPE NCC Staff wrote: * >Dear all, * [..skipped..] * >With an increased demand for independence and multi-homing, the RIPE * >NCC can see the consequences of this in the impressive membership * >growth in the last years: * > * >New LIRs set up per year: * >1997: 262 * >1998: 446 * >1999: 525 * >2000: 865 * >2001: 997 (projected, end of year) * * Do you have similar statistics about PI assignments per year? * * -- * Regards, * Vladimir. * * *
participants (15)
-
Alfredo Sola -
Carlos Friacas -
Dave Pratt -
David R Huberman -
Gert Doering -
Gert Doering, Netmaster -
Hank Nussbacher -
Hans Petter Holen -
Jorma Mellin -
Nurani Nimpuno -
Poul-Henning Kamp -
RIPE NCC Staff -
Roland Perry -
Tanya Hinman -
Vladimir A. Jakovenko