2006-05 New Policy Proposal (PI Assignment Size)
PDP Number: 2006-05 PI Assignment Size Dear Colleagues, A new RIPE Policy has been proposed and is now available for discussion. This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05.html We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 26 September 2006. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer
On Tue, 29 Aug 2006, Filiz Yilmaz wrote:
This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.
http://www.ripe.net/ripe/policies/proposals/2006-05.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 26 September 2006.
Hello. This proposal is proposing the same things I was arguing in my email, so I second this. I have a question though, the proposal includes the notion of "major issue", perhaps this could be specified a bit more? Or is it clear how this would be interpreted by a hostmaster processing an application, that if the customer adds "I need to advertise this on the public internet" it will automatically be known that a at least a /24 is needed? -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, Mikael Abrahamsson wrote:
On Tue, 29 Aug 2006, Filiz Yilmaz wrote:
This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.
http://www.ripe.net/ripe/policies/proposals/2006-05.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 26 September 2006.
Hello. This proposal is proposing the same things I was arguing in my email, so I second this.
I have a question though, the proposal includes the notion of "major issue", perhaps this could be specified a bit more? Or is it clear how this would be interpreted by a hostmaster processing an application, that if the customer adds "I need to advertise this on the public internet" it will automatically be known that a at least a /24 is needed?
i think it's better to be that unspecific then to put in too tight wording - it's a policy, it needs months to be changed again later. Hostmasters@RIPE usually have a fair amount of wisdom :-) As stated earlier, I have no problems with wasting IPv4 address space anymore (there is IPv6, and most projections suggest, there's enough IPv4 space for decades to come, too) - so no problems with the change. Although one should think about what happens if /24 gets "not routable" due to the upcoming next round of memory restrains in BGP routers. Is it /23 then as next minimum? I didn't really get any comments on this a week ago on the discussion leading to this proposal, so i assume, it's not an issue to think about right now for most people? . o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On Tue, 29 Aug 2006, Sascha Lenz wrote:
Although one should think about what happens if /24 gets "not routable" due to the upcoming next round of memory restrains in BGP routers. Is it /23 then as next minimum?
Well, the larger ISPs use routers that can handle more than 240k routes, and as long as they carry the routes, if smaller ISPs filter they will soon see a loss of customers due to this. I also forsee these smaller ISPs getting a default-route as well from their upstreams to handle their inability to handle all routes.
I didn't really get any comments on this a week ago on the discussion leading to this proposal, so i assume, it's not an issue to think about right now for most people?
Well, IPv6 solves the addressing issue but it does nothing for the routing issue. Multihoming in IPv6 is still an issue being debated due to exact same reasons you mention.
. o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..)
Probably because the solution is a radical change from how things are done today and people are quite hesitant to commit to a paradigm shift, especially since the "throw faster hardware at the problem" has worked so far? It would of course be interesting to send the proposal to groups like NANOG and see their reaction, as there are quite a lot of more routing people there that cares less for addressing. -- Mikael Abrahamsson email: swmike@swm.pp.se
Well, IPv6 solves the addressing issue but it does nothing for the routing issue. Multihoming in IPv6 is still an issue being debated due to exact same reasons you mention.
IPv6 allows organizations to REDUCE the number of prefixes that they announce in the global routing table. Most ISPs will only announce one single /32 route in IPv6. This makes a big difference. The debate you refer to is whether or not someone can invent a newer and better way of handling routing in IPv6. Even if they never succeed at this, the same old BGP4 multihoming continues to work with less routes in the IPv6 global routing table than in the IPv4 global routing table. --Michael Dillon
Hi, On Tue, Aug 29, 2006 at 10:58:38AM +0200, Sascha Lenz wrote:
. o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..)
Because it doesn't make a difference. It just means "people will no longer lie to the RIPE hostmasters". What I am really worried about is people getting "lots and lots" of PI, and using multiple routing table slots, instead of getting a reasonable chunk of addresses (however named), and announcing only *one* route. (I'm not talking about TE - this is a can of worms in itself - but about "poor address planning" or "using PI as a substitute for becoming a LIR") Gert Doering -- APWG Co-Chair -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Fri, 2006-09-15 at 21:01 +0200, Gert Doering wrote:
What I am really worried about is people getting "lots and lots" of PI, and using multiple routing table slots, instead of getting a reasonable chunk of addresses (however named), and announcing only *one* route.
This is a critical concern. As it stands, 2006-05 will do little but encourage rampant use of PI space by removing the psychological barrier of lying to RIPE. This is a bad thing: routing tables have once again grown to the extent that they have burst commonly used equipment - the current problem is with dual-stacked SUP720 pfc3a/b modules which now do not have enough tcam to deal with > 192K ipv4 prefixes in their default configuration (although this can be manually tweaked at the inconvenience of a reboot). But we all know this already. I've previously expressed opinions on address-policy-wg about the necessity of charging for PI space, both as a means for discouraging its assignment and for providing a legitimate means to reclaim dead IP space. I have to be honest here and say that this issue needs to be addressed rather more urgently than the proposals in 2006-05. We can continue to lie to RIPE on PI application forms, and they will continue to pretend to believe us so long as the figures add up correctly. But in the interim, PI address space is being lost from the global v4 address pool like a bad memory leak which everyone knows about but no-one wants to fix. Nick
On 15 Sep 2006, at 20:01, Gert Doering wrote:
On Tue, Aug 29, 2006 at 10:58:38AM +0200, Sascha Lenz wrote:
. o O(and i really wonder why there's still no rant about global routing table size increase by allowing routing issues to be PI-assignment relevant..) Because it doesn't make a difference. It just means "people will no longer lie to the RIPE hostmasters". What I am really worried about is people getting "lots and lots" of PI, and using multiple routing table slots, instead of getting a reasonable chunk of addresses (however named), and announcing only *one* route.
There is a real risk that networks due to router resource constraints, who already filter on shorter-than-/24 prefixes will have to cope with any routing table growth by filtering on /23, /22, etc. If we accept argument that we should, as a community, advocate no smaller PI assignments smaller than a /24 because of table filtration, what happens when the table grows to the size that operators start to filter on longer masks ? Andy
Hi, On Sat, Sep 16, 2006 at 06:47:48PM +0100, Andy Davidson wrote:
If we accept argument that we should, as a community, advocate no smaller PI assignments smaller than a /24 because of table filtration, what happens when the table grows to the size that operators start to filter on longer masks ?
In that case, PI receipients holding a /24 suddenly are without connectivity to these networks - and will start yelling at RIPE. Which is basically the point while RIPE (and the RIPE NCC) has previously always refused to make any statements regarding the routeability of a given network size. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi
http://www.ripe.net/ripe/policies/proposals/2006-05.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 26 September 2006.
The proposal make sense but we have to look deeper into the problem of increase the prefixes. If someone ask for multihoming with PI Space, it makes sense that we assign a size which will work with the current filtering policies. But maybe we have to change the policy about PI Space in general ? The question is, which "problems" do we rate as a higher risk; waste of ip space, amount of prefixes, reach ability of a subnet. What do you think ? Regards Erich -- * Erich Hohermuth IP Engineer - SolNet (AS 9044) PGPKEY-46A08FCB * * phone: +41 32 686 8220 / sip:9044*463@inoc-dba.pch.net *
On Tue, Aug 29, 2006 at 11:02:27AM +0200, Erich Hohermuth wrote:
http://www.ripe.net/ripe/policies/proposals/2006-05.html
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 26 September 2006.
The proposal make sense but we have to look deeper into the problem of increase the prefixes. If someone ask for multihoming with PI Space, it makes sense that we assign a size which will work with the current filtering policies. But maybe we have to change the policy about PI Space in general ? The question is, which "problems" do we rate as a higher risk; waste of ip space, amount of prefixes, reach ability of a subnet. What do you think ?
On my practice multihoming PI users ask one more prefix each time the previous one exhausted. Its coused by difficults while receiving one large enough PI subnet. Instead of becoming LIR and have no problems with PA, such users save money and got a couple of small PIs for a space solution... Yeah, here, in xUSSR, it is common practice. :( As IPv4 PI qustion rised again, in my opinion, we have think about reasonable and clear limits for maximum PI assignment size to reduce described above problem and coused routing table impact. -- Dmitry Kiselev
I also support this proposal. Being at the "receiving end" of an ISP, we've seen customer requirements often enough - many times we have been able to redirect the customer wishes towards regular PA space (which of course we'd rather assign, as it keeps customer "in line" more than PI), but larger places often have gone through IP renumbering before (sometimes when switching to us), so they know the cost involved. The prospect of e.g. shelling out the time & money for renumbering again is not very appealing. Of course, those bigger places often require more than a /24, so the issue of non-routable PIs doesn't necessarily apply. Anyway, there are situations where the number of IPs involved is smaller, but the implications are a lot bigger - best example is the current PI I had been asked to request - while the usage is somewhere in the 90 area (totalling in at or around /25+/26 given the network structure and organization), RIPE proposed assigning a /26+/27 which is (of course) useless. While the number of currently used IPs would not necessarily warant a /24 due to rather low work changing THOSE IPs, they are currently in the first roll-out phase of POS terminals - boxes, which have the destination for their communication hard-coded in Flash. Of course chaging one is possible, but imagine doing that on several tenthousands of the boxes at some point ... you will understand that the cost involved is not paid from pocket change ... my mistake was not artificially blowing up the requirements in order to end up in the 230-250 IPs range but attaching a correct, real IP plan ... :( Dmitry Kiselev wrote:
On my practice multihoming PI users ask one more prefix each time the previous one exhausted. Its coused by difficults while receiving one large enough PI subnet. Instead of becoming LIR and have no problems with PA, such users save money and got a couple of small PIs for a space solution... Yeah, here, in xUSSR, it is common practice. :(
What's the point in making end users (as in Companies, etc.) register as an LIR just because they want (or need) a network of their own? The main reason is not being dependent of a single provider, being able to switch providers when technically necessary without a sh@tload of problems and quite non-trivial cost issues afterwards due to changes in IP addresses ... being an LIR is pointless for non-ISPs or SMBs (and most likely for large ones, too). Erich Hohermuth wrote:
increase the prefixes. If someone ask for multihoming with PI Space, it makes sense that we assign a size which will work with the current filtering policies. But maybe we have to change the policy about PI Space in general ? The question is, which "problems" do we rate as a higher risk; waste of ip space, amount of prefixes, reach ability of a subnet. What do you think ?
Multihoming as such I don't see as the core reason for PI space - assigning PA space by two providers isn't a problem, less so than announcing the same size PI prefix, as there should always be a less-specific /19 or bigger to fall back to ... If the amount of prefixes were a reason, shouldn't ISPs be (en)forced to aggregate their announcements? Looking at e.g. the peering tables I get at DECIX or via our uplinks, I see hundreds and thousands of subnets announced by providers from their own PA space, broken down into _many_ subnets, additionally to the aggregated prefix. And I don't think all (or even a mentionable percentage of) those customers are multi-homed and therefore require the smaller announcement be made due to more-specific routing ... at that point, possibly 25% of the routing tables could be saved ... Rather, in order to discourage PI usage by endusers who don't actually need a PI network from a technical standpoint, why not charge an appropriate amount for assigning PI networks? Please correct me if I got this wrong, but at the moment, PI networks count towards the LIR's rating. Which can end up - in a way - to be unfair, as PI networks are requested for end customer, which may at some point in the future switch providers. The points are still counted, even though the provider does not have any revenue to count against it. By defining a rate of €X per /24 would one on hand reduce the requested size of the requests, and also make users think twice about requesting technically unnecessary PI space ... Michael.Dillon@btradianz.com wrote:
If the organization is simultaneously applying for an AS number or the organization already has an AS number, then we should consider routing to be a major issue if the organization says that it is. After all, the only purpose of having an AS number is to do routing.
Indeed. Still, an AS should not be a prerequisite though, as using an PI could be the first part of setting up "advanced routing". Regards, -garry
Hi, On Tue, Aug 29, 2006 at 12:43:22PM +0200, Garry Glendown wrote:
What's the point in making end users (as in Companies, etc.) register as an LIR just because they want (or need) a network of their own?
Discouragement. There are some end users where "everyone agrees" that PI space is a "must", and then there are some where renumbering really would be quick and mostly painless. I strongly think that the latter kind should not be able to get PI space easily, for a one-time-fee, and burden the *recurring cost* for their convenience on everybody else. If we make PI cost a "reasonable" price (like "extra-small LIR") per year, this will not hinder networks that "must have" PI very much - and those that find PI a nice and cheap convenience might reconsider. [..]
If the amount of prefixes were a reason, shouldn't ISPs be (en)forced to aggregate their announcements?
If someone has a good idea how to tackle that, I'd like to hear about it. Really. (But this is only remotely relevant to the ongoing discussion) [..]
Rather, in order to discourage PI usage by endusers who don't actually need a PI network from a technical standpoint, why not charge an appropriate amount for assigning PI networks?
That's the idea.
Please correct me if I got this wrong, but at the moment, PI networks count towards the LIR's rating.
Which means "the LIR pays", which hopefully translates into "the PI holder pays". The problem with the current scheme is that it's a one-time fee, payable only in the year of PI assignment (!), and after that, the PI is free.
Which can end up - in a way - to be unfair, as PI networks are requested for end customer, which may at some point in the future switch providers. The points are still counted, even though the provider does not have any revenue to count against it.
No. The LIR is charged only in the year of PI assignment. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
--On 18 September 2006 17:58 +0200 Gert Doering <gert@space.net> wrote:
The problem with the current scheme is that it's a one-time fee, payable only in the year of PI assignment (!), and after that, the PI is free.
This is important given that there *is* an ongoing cost of PI space (e.g. operating the databases which say who's been allocated what), and this is set to increase if anything, with the plans to digitally sign allocations/assignments in order to increase the security of the routing system (e.g. sBGP). I find myself more in favour of having to "lease" number resources, as long as the cost is reasonable (and we can see to that because of the "bottom-up" process that exists), rather than "buy" them. This will, if anything, help with resource reclamation and re-cycling in the longer term. Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike@linx.net http://www.linx.net/
Mike Hughes wrote:
--On 18 September 2006 17:58 +0200 Gert Doering <gert@space.net> wrote:
The problem with the current scheme is that it's a one-time fee, payable only in the year of PI assignment (!), and after that, the PI is free.
This is important given that there *is* an ongoing cost of PI space (e.g. operating the databases which say who's been allocated what), and this is set to increase if anything, with the plans to digitally sign allocations/assignments in order to increase the security of the routing system (e.g. sBGP).
I find myself more in favour of having to "lease" number resources, as long as the cost is reasonable (and we can see to that because of the "bottom-up" process that exists), rather than "buy" them.
This will, if anything, help with resource reclamation and re-cycling in the longer term.
Leasing sounds good in my book too, especially with schemes like sBGP this will also become easier, as the certificate used for announcing the prefix will have an expiration date, the date of the renewal. Folks who didn't pay their fees automatically loose their ability to announce their prefix. As such sBGP (or a similar method) will introduce quite a new internet era: high security routes, unless an ISP gets compromised, and also the ability to make prefixes illegal very easily. With such a scheme an organization will lease a prefix for X amount of years, they can then in advance of the end date already opt for a refresh of the prefix. Of course, where possible the RIR should make it possible for the leaser to get the same prefix over and over, avoiding the needs to renumber. When the leaser doesn't extend the prefix lease on time the lease expires and the prefix is returned to the free pool. Greets, Jeroen (who indeed would like to see a scheme like sBGP deployed :)
Hi Jeroen, On Mon, 18 Sep 2006 18:33:54 +0200, Jeroen Massar wrote:
(who indeed would like to see a scheme like sBGP deployed :)
The sBGP will consume _significantly_ more resources in the network for even a small amount of sBGP prefixes than PI will consume ever. Crypto Algos require a lot of computational power on conventional CPU's, the very huge majority of backbone routers has no special crypto hardware on board. _If_ sBGB should be implemented, I do sugest to make the BGP PI-friendly (e.g. separation of prefix and AS attributes) in the same step, as sBGB will require an router hardware and software update anyway. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Hi, On Mon, Sep 18, 2006 at 06:52:37PM +0200, Oliver Bartels wrote:
On Mon, 18 Sep 2006 18:33:54 +0200, Jeroen Massar wrote:
(who indeed would like to see a scheme like sBGP deployed :)
The sBGP will consume _significantly_ more resources in the network for even a small amount of sBGP prefixes than PI will consume ever.
There is no need to run the sBGP crypto on all routers on all prefixes in realtime. Especially not on "session startup" time - assuming that a significant set of your neighbour routers have been doing sBGP verification on a largish subset of the routes in their tables, doing the verification as a low-prio thing (and dropping BGP prefixes that fail verification) should suffice. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi Gert, On Mon, 18 Sep 2006 17:58:22 +0200, Gert Doering wrote:
I strongly think that the latter kind should not be able to get PI space easily, for a one-time-fee, and burden the *recurring cost* for their convenience on everybody else.
Your approach sounds like "Planwirtschaft" and generating jobs for buerocrates ("right-to-use PI certification agency auditing office supervisor" ;-/ How about taking the potential money received for PI to finance a better BGP / routing technology or at least memory for poor ISP's ? If we would handle other network technological issues like the "PI is impossible - large tables are impossible" one, we probably would have a "right-to-use-a-9600-baud-modem certification agency" instead of DSL, just because someone would argument that it is impossible to have more than 10 high speed channels on a standard 1000 phone lines copper cable ... Do you remember the old "private modems are bad and will destroy the phone network" arguments from former Bundespost ? The PI routing issue is a technical challenge which cries for an technical solution (yes, large distributed databases do exist) and not for an additional administration. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Hi, On Mon, Sep 18, 2006 at 06:44:37PM +0200, Oliver Bartels wrote:
The PI routing issue is a technical challenge which cries for an technical solution (yes, large distributed databases do exist) and not for an additional administration.
Of course I hope for a technical solution that will solve everything. Until then, I do my best to make sure the network will continue running - and part of that effort is to make sure that costs are at least partially paid by those that have the benefits. If you look at the statistics, you see a significant upturn in PI usage over the last years, and we *do* seem to have exponential growth there. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi Gert, On Mon, 18 Sep 2006 21:59:35 +0200, Gert Doering wrote:
Of course I hope for a technical solution that will solve everything.
Until then, I do my best to make sure the network will continue running - and part of that effort is to make sure that costs are at least partially paid by those that have the benefits.
This is a nice try, however I doubt you will be able to charge those who de-aggregate prefixes and thus cause the vast majority of the table growth. At the end of the day a lot of these de-aggregation results from "security concerns" since 9-11. You may try to charge Mr. Bin Laden, however there are other ones in the queue, too. To keep your network running, you may either: 1. invest or 2. filter those redundant de-agregated announcements (e.g. don't take a /24 with the same AS-path as the /16 it is contained in) However, I know the second (filter) approach _will_ cause your company which pays your salary loosing business, as your company is an transit ISP and thus your customers router will prefer the more specific of your competitor supplying the full table. This should answer the question: # If we accept argument that we should, as a community, advocate no # smaller PI assignments smaller than a /24 because of table # filtration, what happens when the table grows to the size that # operators start to filter on longer masks ? This won't happen, as doing so will cause loss of business for those transit networks which do so. Sadly enough, you should also face that there is nothing, really nothing, that the RIPE can do to stop the table growth influenced by other regions in this world. If the buzzword "security" comes up with large US telcos, this is the end of all discussions in these days. The only thing restrictive policies limited to the RIPE region, as the PI /24 issue and the v6 200 customer rules cause is: - Local ISP's homed in the RIPE region only will be less competitive compared to international ISP's. - People will ly to the hostmasters :-( We should not make policies which cause said disadvantages without having any significant advantage. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
This is a nice try, however I doubt you will be able to charge those who de-aggregate prefixes and thus cause the vast majority of the table growth.
filters
Oliver Bartels wrote:
2. filter those redundant de-agregated announcements (e.g. don't take a /24 with the same AS-path as the /16 it is contained in)
However, I know the second (filter) approach _will_ cause your company which pays your salary loosing business,
It is a good idea to set up the default route to one of upstreams when you set up filtering. This saves routers' memory, but leaves your connectivity fine. You can even accept 0.0.0.0/0 from several upstreams with different localprefs to keep channels back-up working. P.S. I don't believe backbone carriers who don't have upstreams at all need to conserve some extra kilobytes of memory ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi Max, ( and Randy, too, as it hits the same topic ) On Tue, 19 Sep 2006 15:47:51 +0000, Max Tulyev wrote:
It is a good idea to set up the default route to one of upstreams when you set up filtering. This saves routers' memory, but leaves your connectivity fine. You can even accept 0.0.0.0/0 from several upstreams with different localprefs to keep channels back-up working.
This doesn't help the transit provider who is selling upstream to BGP clients. Your default route and Randy's reduced table compete against the full unfiltered table of the other upstream. The more specific prefix _always_ wins.
P.S. I don't believe backbone carriers who don't have upstreams at all need to conserve some extra kilobytes of memory ;)
Ack. In this case there are simply some anti-competitive arguments hidden as resource conservation arguments. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
How about taking the potential money received for PI to finance a better BGP / routing technology or at least memory for poor ISP's ?
Can we please kill this "let's get RIPE/NCC to charge more money for X so that we can give it to Y" idea for once and for all? The RIPE NCC is not a taxation agency. Let's not waste time proposing to turn it into one.
Do you remember the old "private modems are bad and will destroy the phone network" arguments from former Bundespost ?
Yes, we all remember that. Just as we remember the times when - due to routing table growth - a whole pile of different types of equipment were rendered defunct due to their inability to deal with a full routing table, whether through RIB or FIB memory deficiency. At each stage, this cost ISPs a lot of money to rectify. The Bundespost argument (repeated by pretty much all telcos worldwide, as far as I can tell) was to a large extent FUD based on presumption and fear of the unknown. Routing table growth is a well defined phenomenon which costs real money to deal with. [Incidentally, we also remember the NFSnet $15 domain tax and the way that it was declared illegal.]
The PI routing issue is a technical challenge which cries for an technical solution (yes, large distributed databases do exist) and not for an additional administration.
The "PI routing issue" does not exist, at least in the terms that you're using here. What exists is a large growth in routing table size, due to - inter-alia - PI announcements, PA subnet announcements and the fast organic growth of full PA netblocks. Also, large distributed databases are of no real relevance to switching IP packets at 10G speeds. However, this is not particularly relevant to proposal 2006-05. The proposal may - slightly - increase the rate of uptake of PI assignments in the RIPE catchment area, and this may proportionally increase the number of prefixes in the routing tables. But the only thing that's stopping people from registering /24's at the moment where they really need less than this amount of space, is their inclination not to lie to RIPE. Removing this (almost) requirement to lie to get a /24 is not going to open up the flood gates and cause the internet to collapse. Nick
Hi Nick, On Mon, 18 Sep 2006 22:07:36 +0100, Nick Hilliard wrote:
How about taking the potential money received for PI to finance a better BGP / routing technology or at least memory for poor ISP's ?
Can we please kill this "let's get RIPE/NCC to charge more money for X so that we can give it to Y" idea for once and for all?
Fully agree. I just used this argument to demonstrate the effect of "let us charge money and build administrations".
The Bundespost argument (repeated by pretty much all telcos worldwide, as far as I can tell) was to a large extent FUD based on presumption and fear of the unknown. Routing table growth is a well defined phenomenon which costs real money to deal with.
In the 9600 baud modem age it was also possible to use a 2 MBit/s line as the international uplink of a national ISP. Today we have to invest into fibre links which cost real money to deal with. We should think of restricting high bandwidth applications by RIPE to certain adresses and create a high speed permit agency ;-/
The "PI routing issue" does not exist, at least in the terms that you're using here. What exists is a large growth in routing table size, due to - inter-alia - PI announcements, PA subnet announcements and the fast organic growth of full PA netblocks.
And most of the table growth is due de-aggregation of large prefixes into bundles of subnets in non-RIPE regions. The policy of the RIPE NCC will change _nothing_ with this, as an ISP you will have to face the fact that routers will need more resources in the future.
Also, large distributed databases are of no real relevance to switching IP packets at 10G speeds.
There are technical solutions for technical challenges ... A distributed database with 180k prefixes is not really large using todays hardware. In my opinion the "memory problem" just exists because of the sell-next-level-due-to-hardware-limits policy of some router vendors. Interesting: Take the 256 MByte roughly required on some systems for a two upstreams full table, subtract 1/4 for the OS and divide the difference by 180k, this yields about 1100 bytes per prefix. Yes, 1100 byte. You may probably store the whole written history of all PI end site companies within this space. Just for your information: - One of the backbone routers with full-mesh and full-table this email is passed over just takes 30 MBytes (!) for the whole 180k prefix RIB. And it works as expected. Just to show that things can be made better.
However, this is not particularly relevant to proposal 2006-05. The proposal may - slightly - increase the rate of uptake of PI assignments in the RIPE catchment area, and this may proportionally increase the number of prefixes in the routing tables. But the only thing that's stopping people from registering /24's at the moment where they really need less than this amount of space, is their inclination not to lie to RIPE. Removing this (almost) requirement to lie to get a /24 is not going to open up the flood gates and cause the internet to collapse.
Agree. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
Gert Doering wrote:
If we make PI cost a "reasonable" price (like "extra-small LIR") per year, this will not hinder networks that "must have" PI very much - and those that find PI a nice and cheap convenience might reconsider.
In this case, at first you are going to kill a small and extra-small business (I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves) as well as non-commertial and educational requesters. Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price. And no technician can argue with that. So instead of PI /24 they really need, they get a LIR with at least /21 they really don't need in any case. And we loose in conservation of address space in 8 times (not winning in aggregation any percent)!!! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, On Tue, Sep 19, 2006 at 03:34:58PM +0000, Max Tulyev wrote:
In this case, at first you are going to kill a small and extra-small business (I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves) as well as non-commertial and educational requesters.
While this is a nice argument, I don't really see why I am supposed to sponsor these entities. If they think they need to put a burden on global routing, they can pay for it - and if they think that's too expensive, they can use PA space, and renumber every now and then. Nobody is aiming to exclude people from participating in the Internet, but PI isn't the *only* way.
Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price. And no technician can argue with that. So instead of PI /24 they really need, they get a LIR with at least /21 they really don't need in any case. And we loose in conservation of address space in 8 times (not winning in aggregation any percent)!!!
Actually, I see this as a win - as soon as the /24 is full, we have a second entry in the routing table (for the next PI), while with a /21, the single routing table entry will last a lot longer. This is what is happening right now - people get multiple PI assignments, instead of a single larger block. (Besides this, nobody said that the price would have to be the *same* - I specifically mentioned the "extra small" LIR category) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Nobody is aiming to exclude people from participating in the Internet, but PI isn't the *only* way.
IP addresses (PA and PI) are not just used for the Internet. Many IP address blocks are only used on IP internetworks that are not part of the public Internet. Some of these internetworks allow limited traffic exchange with the public Internet through NAT gateways. Others allow no traffic interchange at all and enforce this with firewalls in case participants fail to maintain the air gap between their Internet connections and the other internetwork. Most of these IP address blocks, PI and PA, are not used by a military organization. They tend to be used by business federations and by companies providing a business service to customers over a non-public internetwork. RFC 2050 paragraph 3(a) specifically allows for IP address allocations/assignments to these non-Internet uses. When RIPE is making policy about IP address use, we should be careful to not be Internet-centric because that could be interpreted as anti-competition. Companies can justify PI assignments or PA allocations/assignments independently of whether they intend to connect to the public Internet. As far as participating in the Internet, not all organizations necessarily want 100% global connectivity. In particular, organizations in countries with a non-colonial language may only want connectivity to a few countries which they consider to be their "community" or their "market". For the record, colonial languages are those like English, French, Spanish, and Russian which are widely used outside of their area of origin due to a previous history as the language of empire. You can understand that a business who markets services in Hungarian might only want connectivity to Hungary, Rumania, Austria, Slovakia, and Ukraine where there is a population of Hungarian native speakers. They might do this by buying connectivity to multiple local ISPs in this region and asking those ISPs to not forward their announced route(s). That is a valid use of a PI assignment for multihoming that does not result in the use of a slot in the global routing table. --Michael Dillon P.S. my choice of Hungarian was entirely random. The same thing applies for languages like Catalan, Italian, Albanian, German, etc.
Hi, On Tue, Sep 19, 2006 at 02:17:13PM +0100, Michael.Dillon@btradianz.com wrote:
Hungarian might only want connectivity to Hungary, Rumania, Austria, Slovakia, and Ukraine where there is a population of Hungarian native speakers. They might do this by buying connectivity to multiple local ISPs in this region and asking those ISPs to not forward their announced route(s).
While this sounds like a theoretical possiblity, I haven't seen any real-world example yet (and I'm from a region with "non-colonial" language)... I do see the use of PI for "private interconnections", though - and some thought needs to go into "how to handle those", yes. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Gert Doering wrote:
(Besides this, nobody said that the price would have to be the *same* - I specifically mentioned the "extra small" LIR category)
Yep, it is certainly minimum /21 PA I said ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hello! On Tue, Sep 19, 2006 at 03:34:58PM +0000, Max Tulyev wrote:
If we make PI cost a "reasonable" price (like "extra-small LIR") per year, this will not hinder networks that "must have" PI very much - and those that find PI a nice and cheap convenience might reconsider.
In this case, at first you are going to kill a small and extra-small business (I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves) as well as non-commertial and educational requesters.
Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price. And no technician can argue with that. So instead of PI /24 they really need, they get a LIR with at least /21 they really don't need in any case. And we loose in conservation of address space in 8 times (not winning in aggregation any percent)!!!
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment. -- Dmitry Kiselev
Dmitry Kiselev wrote:
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.
Seems to be very reasonable. For example, as it was a long before. But there should be a schema how I can pass mntner to client, and therefore "block" (or remove) objects in case of payment stops. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Tue, 19 Sep 2006, Max Tulyev wrote:
Dmitry Kiselev wrote:
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.
Seems to be very reasonable. For example, as it was a long before.
Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht... for an example I've been tracking for 5 years now (company bankrupt). ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd. 19981211 212.77.128/19 ALLOCATED PA So in theory your idea sounds nice. In practice it doesn't work. Regards, -Hank Nussbacher http://www.interall.co.il
Hi Hank! This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs. But. If there is PI space (and ASes not associated with LIR company) - there is also third party: end-user. He shouldn't have any troubles if LIR goes out of business or became unlucky in it. I have a large experience in providing PI/AS (even own a LIR with primary service is PI assignment i ex-USSR). My opinion is: 1. PI is a GOOD thing. 1a. It stimulates small and medium business, providing Internet in regions with a lack of money. Yes, EUR2000 really can be a yearly turnover of small Internet company here. 1b. It conserves IP space (people do request as many space as they really need, not /21 "because it is given at LIR startup") 2. PI and AS SHOULD be billed in the regular basis (yearly, quarterly or so). This pervents dead IP space beeing locked. 3. There shoud be an mechanism (NOT mntner as it is now) to suspend and remove address space if there is no payments. Again, _not_ LIR's mntner in object. 4. There should be clear and simply mechanism ("what-to-do, step-by-step") how PI end-user can change LIR if something goes wrong (LIR is out of business, and even LIR goes mad). 4a. This mechanism should be quite easy and clear so anyone can get rid in it in ten minutes, therefore there should be something to stop user switching between LIRs looking where is cheaper (and in practice, killing the market by some inadequate players will do demping). 5. Of course, RIPE (LIR?) should check actuality of contact information of that kind of objects. Or if not really check - have an ability to suspend objects if this information is invalid (i.e. RIPE can't contact user with that information). Yes, I think there should be "suspended" objects: not visible in the database (or visible with some flag, but not routeable - without route objects or so). These objects can be returned to life in some cases (user at least payed a bill, provided actual contacts or so) or wiped in some other cases. Maybe, we should learn things from domain name registering systems. If it is interesting, I can do something like presentation or policy draft? So it is a good topic to talk at the RIPE meeting anyway ;) Hank Nussbacher wrote:
On Tue, 19 Sep 2006, Max Tulyev wrote:
Dmitry Kiselev wrote:
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.
Seems to be very reasonable. For example, as it was a long before.
Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...
for an example I've been tracking for 5 years now (company bankrupt).
ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.
19981211 212.77.128/19 ALLOCATED PA
So in theory your idea sounds nice. In practice it doesn't work.
Regards, -Hank Nussbacher http://www.interall.co.il
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, Max! On Tue, Sep 19, 2006 at 10:30:33PM +0400, Max Tulyev wrote:
This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.
But. If there is PI space (and ASes not associated with LIR company) - there is also third party: end-user. He shouldn't have any troubles if LIR goes out of business or became unlucky in it.
I have a large experience in providing PI/AS (even own a LIR with primary service is PI assignment i ex-USSR).
My opinion is:
1. PI is a GOOD thing. 1a. It stimulates small and medium business, providing Internet in regions with a lack of money. Yes, EUR2000 really can be a yearly turnover of small Internet company here. 1b. It conserves IP space (people do request as many space as they really need, not /21 "because it is given at LIR startup") 2. PI and AS SHOULD be billed in the regular basis (yearly, quarterly or so). This pervents dead IP space beeing locked. 3. There shoud be an mechanism (NOT mntner as it is now) to suspend and remove address space if there is no payments. Again, _not_ LIR's mntner in object. 4. There should be clear and simply mechanism ("what-to-do, step-by-step") how PI end-user can change LIR if something goes wrong (LIR is out of business, and even LIR goes mad). 4a. This mechanism should be quite easy and clear so anyone can get rid in it in ten minutes, therefore there should be something to stop user switching between LIRs looking where is cheaper (and in practice, killing the market by some inadequate players will do demping). 5. Of course, RIPE (LIR?) should check actuality of contact information of that kind of objects. Or if not really check - have an ability to suspend objects if this information is invalid (i.e. RIPE can't contact user with that information).
Yes, I think there should be "suspended" objects: not visible in the database (or visible with some flag, but not routeable - without route objects or so). These objects can be returned to life in some cases (user at least payed a bill, provided actual contacts or so) or wiped in some other cases.
Maybe, we should learn things from domain name registering systems.
If it is interesting, I can do something like presentation or policy draft? So it is a good topic to talk at the RIPE meeting anyway ;)
According to current IPv4 Address Policy PI address space should be ASSIGNED to END USERS ONLY. ISP usually provide service for some (or many) organizations, i.e. contact info for some ranges may be very different. Although ISP is close to its customers they are different companies - end-users in Policy terms. ISP with PI can't create separate DB records and it is violate section 4.0 of Policy. It is violate item 5 from Your opinion quoted above too. ;) Since PA have no such disadvantages and have a good scale capability it should be used by ISPs. PI is still good for small/medium *enterprises* which large enough to do multihoming.
On Tue, 19 Sep 2006, Max Tulyev wrote:
Dmitry Kiselev wrote:
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.
Seems to be very reasonable. For example, as it was a long before.
Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...
for an example I've been tracking for 5 years now (company bankrupt).
ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.
19981211 212.77.128/19 ALLOCATED PA
So in theory your idea sounds nice. In practice it doesn't work.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
-- Dmitry Kiselev
On Wed, Sep 20, 2006 at 11:51:59AM +0300, Dmitry Kiselev wrote:
This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.
According to current IPv4 Address Policy PI address space should be ASSIGNED to END USERS ONLY. ISP usually provide service for some (or many) organizations, i.e. contact info for some ranges may be very different. Although ISP is close to its customers they are different companies - end-users in Policy terms. ISP with PI can't create separate DB records and it is violate section 4.0 of Policy. It is violate item 5 from Your opinion quoted above too. ;)
Since PA have no such disadvantages and have a good scale capability it should be used by ISPs. PI is still good for small/medium *enterprises* which large enough to do multihoming. And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). The only advantage of PI's is that customer doesn't needs to be renumbered if he leaves his primary ISP.
On Tue, 19 Sep 2006, Max Tulyev wrote:
Dmitry Kiselev wrote:
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.
Seems to be very reasonable. For example, as it was a long before.
Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...
for an example I've been tracking for 5 years now (company bankrupt).
ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.
19981211 212.77.128/19 ALLOCATED PA
So in theory your idea sounds nice. In practice it doesn't work.
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
-- Dmitry Kiselev
-- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).
It's nothing to do with your LIR. You can only do this if your secondary upstream agrees to it. Your LIR can shout and jump up and down and tell you not to do this, but they can't stop their competitor from leaking a prefix which they really shouldn't. Fortunately, most ISPs won't do this sort of thing. Nick
On Wed, Sep 20, 2006 at 02:54:09PM +0100, Nick Hilliard wrote:
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).
It's nothing to do with your LIR. You can only do this if your secondary upstream agrees to it. Your LIR can shout and jump up and down and tell you not to do this, but they can't stop their competitor from leaking a prefix which they really shouldn't. Mm... In most cases, LIR protects (Or at least, should protect, I think) PA assigments by his own mntner. Secondary upstream can't create route object on this specific PA assigment from first LIR without agreement, and this prefix wouldn't be routed in Internet normally.
Fortunately, most ISPs won't do this sort of thing.
Nick
-- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address
It's nothing to do with your LIR. You can only do this if your secondary upstream agrees to it. Your LIR can shout and jump up and down and tell you not to do this, but they can't stop their competitor from leaking a prefix which they really shouldn't.
Fortunately, most ISPs won't do this sort of thing.
Which is unfortunate. Because if scaling of the global routing table is really as big of an issue as some people claim, then the above scenario defines a BEST PRACTICE for multihoming without global impact. But, as I said in my last message, without a globally agreed definition of the problem and a globally agreed way forward to solving it, any action that RIPE takes to limit growth of the global routing table is just penalizing European businesses for no net benefit. PI assignments are a good thing because they help get organizations online. When an organization needs this kind of address range, RIPE should be ready to give it to them. In the end, all assignments and allocations are subject to technical justifications based on RFC 2050. --Michael Dillon P.S. I happen to believe that there are issues with scaling the global routing table but I believe that it is better to solve those issues directly, and not indirectly through RIR policies. A direct solution can only come from a direct discussion, not random complaints in various RIR address policy forums.
Which is unfortunate. Because if scaling of the global routing table is really as big of an issue as some people claim,
It's just an issue which crops up again and again, and costs money to solve each time. I've got a bunch of dual stacked sup720 pfc3b's. These no longer take a full v4 routing table in their default configuration, and shortly, I expect them not to be able to take a full v4 routing table using any soft configuration, except by filtering out routes. Yes, I can upgrade them. But it's an issue. It means downtime and lots of €€€.
then the above scenario defines a BEST PRACTICE for multihoming without global impact.
Let's be fair here - it's half-baked multihoming. If your connection to your LIR network goes down, you're going to be left with patchy connectivity at best. Half baked != best practice.
But, as I said in my last message, without a globally agreed definition of the problem and a globally agreed way forward to solving it, any action that RIPE takes to limit growth of the global routing table is just penalizing European businesses for no net benefit.
But, but, but, but.... in this proposal, RIPE is not taking action to limit the growth of the global routing table. Under the terms of 2006-05, the intent is to make RIPE PI assignments more useful in the Internet, which makes PI a more attractive option, which helps European businesses.
PI assignments are a good thing because they help get organizations online. When an organization needs this kind of address range, RIPE should be ready to give it to them. In the end, all assignments and allocations are subject to technical justifications based on RFC 2050.
Exactly - this is what this proposal is about. Separate to this proposal are the following items of note: 1. 2006-05 affects address assignment policy, and address assignment policy indirectly affects routing table growth, 2. we have no garbage collection mechanism for stale PI assignments, 3. readily available PI is good for business, 4. lots of people believe - with good reason - that readily available PI is bad news from a network scalability point of view, and therefore: 5. one of the reasons that people might be unhappy about this proposal is because it may increase the amount of PI space assigned by RIPE. Nick
Which is unfortunate. Because if scaling of the global routing table is really as big of an issue as some people claim,
It's just an issue which crops up again and again, and costs money to solve each time. I've got a bunch of dual stacked sup720 pfc3b's. These no longer take a full v4 routing table in their default configuration, and shortly, I expect them not to be able to take a full v4 routing table using any soft configuration, except by filtering out routes.
Yes, I can upgrade them. But it's an issue. It means downtime and lots of ¤¤¤.
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).
Some traffic flows on default gateway, even if you have BGP full view on the router... :) Normally, longest prefix has highest priority. If your multihomed prefix doesn't exist in some part of Internet, you may have troubles with connectivity with this part of Internet, don't looking PA or PI addresses you uses.
Sorry to say, but you're running an ISP on 6500's and propose a problem with upgrading PFC-3B to PFC-3BXL at about 6.000 - 9.000 $ per engine ? Besides that, you bought a 256k prefixes engine about 2 years ago (i think it was released about sometime 2004) ? There's not only an issue of routing / routing table scalibity but also an issue of network scalability. The latter is in the sole responsibility of the ISP / LIR. Instead of table size/memory issues due to table growth we could also discuss about CPU utilization issues due to BGP updates. Did you check the CPU load of your sup720 loaded with a bunch of session ? The current number of constant updates triggers about 10-20% (at least) load on 3BXL engines when connected with decix peers and an upstream for example. Maybe we should propose serious actions to be taken against flapping systems, software- and standard-pc - based (zebra, quagga, etc.) networks, too ... /-( And in my opinion include bgp links across links of 2-4 mbit/s of bandwidth to the list above - usually those are encountered to satisfy the 2-upstreams-rule. As long as I see ASN >= 64512, prefixes down to /30, /16's with sub-advertisements of 200 /24's with the same as path, packets with source addresses out of RFC 1918 ranges even via large multinational ASN sessions, I believe there're more important general operating problems than a bunch of PI prefixes. IMHO the massive de-aggrations hurt much more (and yes, we're doing some of that ourselves). There're a lot of operational problems currently existing so why bother about a few more PI prefixes and introduce additional administrative and operational overhead ? Most time I spend with PI-related problems are advertisements < /24 sent by customers (and therefore dropped) filing a complaint later, LIR not responding to db object transfer request, inaccurate or outdated db information etc. But these won't solve by further constraining PI assignments. Remember, a PI request has to be filed with RIPE by a LIR. You can refuse the customers wishes - but that customer will find some LIR that will do just to take over the customer from you. Those arguments lead to the same discussion fought out in the IPv6 PI discussion: if the internet's end users (customers) are denied their requests by policies and their wishes are ignored, those areas will starve in the long run. regards, Marcus ------------------------------------------ Tropolys Rhein-Main GmbH Versatel Group Network Engineering and Administration ------------------------------------------ ASN 8881 / 15837 MG3031-RIPE ------------------------------------------
Hi! On Wed, Sep 20, 2006 at 04:21:27PM +0400, Gennady Abramov wrote:
This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.
According to current IPv4 Address Policy PI address space should be ASSIGNED to END USERS ONLY. ISP usually provide service for some (or many) organizations, i.e. contact info for some ranges may be very different. Although ISP is close to its customers they are different companies - end-users in Policy terms. ISP with PI can't create separate DB records and it is violate section 4.0 of Policy. It is violate item 5 from Your opinion quoted above too. ;)
Since PA have no such disadvantages and have a good scale capability it should be used by ISPs. PI is still good for small/medium *enterprises* which large enough to do multihoming. And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). The only advantage of PI's is that customer doesn't needs to be renumbered if he leaves his primary ISP.
...and does not pay any money! ;) It is major argument for most of PI holders.
Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment.
Seems to be very reasonable. For example, as it was a long before.
Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.ht...
for an example I've been tracking for 5 years now (company bankrupt).
ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd.
19981211 212.77.128/19 ALLOCATED PA
So in theory your idea sounds nice. In practice it doesn't work.
-- Dmitry Kiselev
Dmitry Kiselev wrote:
...and does not pay any money! ;) It is major argument for most of PI holders.
You know, nothing is strengthen user's confidence as well as prepayment ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Gennady Abramov wrote:
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).
Multihoming, but not backups. Because of some traffic will flow through [aggregated] LIR route if even link with LIR will be damaged. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Gennady Abramov wrote:
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it).
Multihoming, but not backups. Because of some traffic will flow through [aggregated] LIR route if even link with LIR will be damaged. It is very some traffic. Some traffic flows on default gateway, even if you have BGP full view on
On Wed, Sep 20, 2006 at 06:03:09PM +0000, Max Tulyev wrote: the router... :) Normally, longest prefix has highest priority. If your multihomed prefix doesn't exist in some part of Internet, you may have troubles with connectivity with this part of Internet, don't looking PA or PI addresses you uses. In the case of PA specific, traffic from this part of Internet will flow to aggregated route, and, if specific route would be found on next hops, will go to specific route from this next hops. In the case of PI, traffic will flow to default or will be dropped. Anyway, if your prefix doesn't routed anywhere, it isn't normal situation, don't depend of addresses u use. -- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address
Gennady Abramov wrote:
Gennady Abramov wrote:
And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). Multihoming, but not backups. Because of some traffic will flow through [aggregated] LIR route if even link with LIR will be damaged. It is very some traffic. Some traffic flows on default gateway, even if you have BGP full view on
On Wed, Sep 20, 2006 at 06:03:09PM +0000, Max Tulyev wrote: the router... :) Normally, longest prefix has highest priority. If your multihomed prefix doesn't exist in some part of Internet, you may have troubles with connectivity with this part of Internet, don't looking PA or PI addresses you uses. In the case of PA specific, traffic from this part of Internet will flow to aggregated route, and, if specific route would be found on next hops, will go to specific route from this next hops. In the case of PI, traffic will flow to default or will be dropped. Anyway, if your prefix doesn't routed anywhere, it isn't normal situation, don't depend of addresses u use.
Good only in the theory ;) IRL some "wise" admins filters out more specific if there is less specific (? - as I can understand this). This means some part of Internet will be not accessible if there is no link between you and your LIR. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max Tulyev wrote:
This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.
You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ? The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ... RIPE NCC possibly have no contract with the companies that would need to stop accepting the prefixes from the debting party. -a
On Thu, 2006-09-21 at 02:00 +0100, Andy Davidson wrote:
Max Tulyev wrote:
This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs.
You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ?
What the immediate upstream may think would be irrelevant. *If* there is *ever* consensus within the RIPE community to have the NCC reclaim blocks, there would have to be mechanisms in place to enforce the decision. That would most probably involve a quarantine period for reclaimed prefixes during which transit providers in the region would be asked to black-hole the space.
The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ...
It only takes a handful of large transit providers to black-hole a prefix to render that address-block useless.
RIPE NCC possibly have no contract with the companies that would need to stop accepting the prefixes from the debting party.
There are more than enough transit-providers on contract. The immediate upstream of the reclaimed block alone makes no difference. The question isn't if it can be done or not, but whether the RIPE community as a whole really wants such a scheme to be implemented. -- Per Heldal - http://heldal.eml.cc/
Hi Per, On 21 Sep 2006, at 4:17GMT+02:00, Per Heldal wrote: [...]
What the immediate upstream may think would be irrelevant. *If* there is *ever* consensus within the RIPE community to have the NCC reclaim blocks, there would have to be mechanisms in place to enforce the decision. That would most probably involve a quarantine period for reclaimed prefixes during which transit providers in the region would be asked to black-hole the space.
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year. Regards, -- leo vegoda Registration Services Manager RIPE NCC
leo vegoda wrote:
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.
And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi Max, On 21 Sep 2006, at 7:41GMT+02:00, Max Tulyev wrote:
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.
And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?
The RIPE NCC has no authority over routing decisions taken by network operators. Regards, -- leo vegoda Registration Services Manager RIPE NCC
On 21 Sep, 2006, at 15:50, leo vegoda wrote:
Hi Max,
On 21 Sep 2006, at 7:41GMT+02:00, Max Tulyev wrote:
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.
And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?
The RIPE NCC has no authority over routing decisions taken by network operators.
Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right? Joao
Hi Joao, On 22 Sep 2006, at 10:19GMT+02:00, Joao Damas wrote: [...]
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.
And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?
The RIPE NCC has no authority over routing decisions taken by network operators.
Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right?
If a network is announcing address space that has been returned to us there will not be a registration for the specific prefix being announced, just a registration for the allocation from which it is 'taken'. Regards, -- leo vegoda Registration Services Manager RIPE NCC
But this is nothing special imho, the very same statement holds true for any space that as yet hadn't been "in use" at all. Bottom line: if there isn't a record to properly docment assignment to an end site, then the use or routing of that address space is at least vey, very, questionable(1). But if you don't double-check - you'll never know ;-) Wilfried. (1) announcement of a full PA allocation as one route, covering as yet unassigned space, is an exception to this rule. leo vegoda wrote:
Hi Joao,
On 22 Sep 2006, at 10:19GMT+02:00, Joao Damas wrote:
[...]
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.
And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?
The RIPE NCC has no authority over routing decisions taken by network operators.
Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right?
If a network is announcing address space that has been returned to us there will not be a registration for the specific prefix being announced, just a registration for the allocation from which it is 'taken'.
Regards,
Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right?
if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources. randy
Randy Bush wrote:
Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right?
if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources.
As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources.
As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it?
the current work will provide a formally verifiable demonstration of ownership of address space. to achieve your goal _formally_ will require something like sbgp. the irr is an informal way to kinda achieve what you want. and we use it today. one first useful step for an isp is to use the x.509 data to verify ownership assertions in the irr when building filter lists, for example. randy
On Mon, Sep 25, 2006 at 06:43:40AM -1000, Randy Bush wrote:
if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources.
As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it?
the current work will provide a formally verifiable demonstration of ownership of address space.
wow... address ownership. thats kind of a new concept. last i checked, most RIRs deal with the concept of address stewardship. does that mean i can assert ownership of integers and the RIR system will back me up?
one first useful step for an isp is to use the x.509 data to verify ownership assertions in the irr when building filter lists, for example. randy
--bill
wow... address ownership. thats kind of a new concept. last i checked, most RIRs deal with the concept of address stewardship. does that mean i can assert ownership of integers and the RIR system will back me up?
thanks for very educational contribution. randy
On Mon, Sep 25, 2006 at 08:40:18AM -1000, Randy Bush wrote:
wow... address ownership. thats kind of a new concept. last i checked, most RIRs deal with the concept of address stewardship. does that mean i can assert ownership of integers and the RIR system will back me up?
thanks for very educational contribution.
randy
your welcome. and unless you have verifiable information to the contrary, i (for one) would appreciate it if you would be more precise regarding address allocation/delegation and stewardship. To my understanding, addresses are NOT property and can not be owned. I will be pleased to be reliably informed otherwise. Please educate me here. --bill
your welcome. and unless you have verifiable information to the contrary, i (for one) would appreciate it if you would be more precise regarding address allocation/delegation and stewardship. To my understanding, addresses are NOT property and can not be owned. I will be pleased to be reliably informed otherwise. Please educate me here.
sorry, bill. i stick to engineering and leave layers 9-42 to experts such as yourself. but good red herring (sorry for idiom. red herrings are a bad smell dragged across a trail to keep others from being able to follow it). randy
Randy Bush wrote:
if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources. As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it?
the current work will provide a formally verifiable demonstration of ownership of address space.
to achieve your goal _formally_ will require something like sbgp.
the irr is an informal way to kinda achieve what you want. and we use it today.
one first useful step for an isp is to use the x.509 data to verify ownership assertions in the irr when building filter lists, for example.
I just think (if I correct understood that, sorry but this RFC is not easy reading) small enhancement of this will give us the large improvement: we can do filtering of unauthorized announcements (announcements of right prefix originated with right AS but from wrong place)! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
I just think (if I correct understood that, sorry but this RFC is not easy reading) small enhancement of this will give us the large improvement: we can do filtering of unauthorized announcements (announcements of right prefix originated with right AS but from wrong place)!
will need one more thing to verify origin, what is called a Routing Origination Authority, which looks a lot like a cert and is stored in the infrastructure, but which binds a cert of address ownership to the as number which is authorized to announce it. this would be verifiably signed by the formal owner of the address space. randy
On Mon, 25 Sep 2006, Randy Bush wrote: <snip>
will need one more thing to verify origin, what is called a Routing Origination Authority, which looks a lot like a cert and is stored in the infrastructure, but which binds a cert of address ownership to the as number which is authorized to announce it. this would be verifiably signed by the formal owner of the address space.
Hope you don't mean ownership as in really own it forever, but more like right to use it if you've payed your fee etc ? -- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Hi, On Tue, Sep 26, 2006 at 10:06:26AM +0200, Roger Jorgensen wrote:
Hope you don't mean ownership as in really own it forever, but more like right to use it if you've payed your fee etc ?
Exactly. Certificates have a lifetime, if you don't pay your fee, the cert will not be renewed. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Tue, 26 Sep 2006, Roger Jorgensen wrote: Why not just replace the word "owner" with "leaser"? I always assumed that I was leasing IP address space from the RIRs and not owning it. -Hank
On Mon, 25 Sep 2006, Randy Bush wrote: <snip>
will need one more thing to verify origin, what is called a Routing Origination Authority, which looks a lot like a cert and is stored in the infrastructure, but which binds a cert of address ownership to the as number which is authorized to announce it. this would be verifiably signed by the formal owner of the address space.
Hope you don't mean ownership as in really own it forever, but more like right to use it if you've payed your fee etc ?
--
------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
+++++++++++++++++++++++++++++++++++++++++++ This Mail Was Scanned By Mail-seCure System at the Tel-Aviv University CC.
Hi! On Thu, Sep 21, 2006 at 05:41:14PM +0000, Max Tulyev wrote:
We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year.
And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case?
Yeah... RIPE has SWAT for such cases... :) :D Joke. IMHO, RIPE can only inform community about collision and point to legal network owner. -- Dmitry Kiselev
Per Heldal wrote:
What the immediate upstream may think would be irrelevant. *If* there is *ever* consensus within the RIPE community to have the NCC reclaim blocks, there would have to be mechanisms in place to enforce the decision. That would most probably involve a quarantine period for reclaimed prefixes during which transit providers in the region would be asked to black-hole the space.
No, not black-hole! Just don't accept! Because of there will be another period of "de-black-holing" ;) and so on...
It only takes a handful of large transit providers to black-hole a prefix to render that address-block useless.
Again, if there is no inetnum/as/roure objects, "large transit providers" just drop this because of RR DB filters. This also true for those who "transmit pirate signal into the Matrix" ;) using fake IPs and ASes.
The question isn't if it can be done or not, but whether the RIPE community as a whole really wants such a scheme to be implemented.
I think it must be done. Not only because of this case, but also for blocking unauthorized announces. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
You're opening up a huge can of worms here.
Aye, surely. 10 years ago, a survey was done on the 192/8 swamp, and it was estimated that even at that stage, 60% of the registrations were uncontactable. I can't see how thing would have got better in the interim, but does this mean that we officially declare this space lost? Whatever about reclaiming blocks previously assigned, what about blocks assigned in the future? Are we also going to commit right now to losing these blocks if they are unused, or are we going to attempt to fix the issue? I mean, there's a massive problem here. Losing IP space to posterity just because we can't be bothered to put policies in place to deal with the issue is frankly rather unwise.
'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ? The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ...
The RIPE NCC is not the routing police; it's a registration clearing-house. LIR's pay money to guarantee that the address space blocks they are allocated are globally unique. It's up to carriers to ensure that their customers' announcements are legitimate. Anyway, this is getting seriously off topic for 2006-05. Nick
You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ?
The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ...
RIPE NCC possibly have no contract with the companies that would need to stop accepting the prefixes from the debting party. The deletion of "route:" object means troubles with routing of the
On Thu, Sep 21, 2006 at 02:00:20AM +0100, Andy Davidson wrote: prefix. Of course, it is possible to route prefix without corresponding "route:", but it isn't very easy. And, of course, forget of any routing policy with this prefix, you may just to place this prefix to the Internet somehow. Of course, if you can (Talk with your upstreams to configure "hand-made" filters, or get an upstream who will accept "any" from you and have such peers and upstreams, etc). -- С уважением, Абрамов Геннадий, CCNP Отдел сетевого управления (NOC) ЗАО "Демос-Интернет" Тел.: (495) 737-0436 http://www.demos.ru/address
Andy Davidson wrote:
You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ? The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ...
It means. Just because of this space will not be routed in the world. RR DB is a good thing! ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
(I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves)
Um. No. It is also people who have experienced the "joys" of watching routers falls over (and the subsequent cascading failures) because of too much routing information and who wish to avoid similar happy experiences in the future. Simply, PI to network topological leaves doesn't scale. Rgds, -drc "Those who cannot remember the past are condemned to repeat it." -- George Santayana
David Conrad wrote:
Simply, PI to network topological leaves doesn't scale. I think it is not an argument for PI. You also can't scale PA when it ends. You only can allocate new one.
It is an argument for thinking before doing. Best way is to set up period of requesting, i.e. one company can do same kind of requests for example once in two years. It makes a company think twice about scaling ("do we requesting enough space for our grow?") and about conserving ("we have to pay more for more space"). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max, On Sep 19, 2006, at 11:37 AM, Max Tulyev wrote:
David Conrad wrote:
Simply, PI to network topological leaves doesn't scale. I think it is not an argument for PI.
Right. It is an argument against PI.
You also can't scale PA when it ends. You only can allocate new one.
The difference, of course, is that PA (by definition) can be aggregated into a single announcement, thereby reducing the amount of information sloshing around the routing system. It is true that if an ISP runs out of PA prefixes to assign to their customers that they'll need to get another one and that additional prefix will need to be PI, but that is a single prefix that aggregates all the customers numbered out of that prefix. This is Routing Scalability 101.
It is an argument for thinking before doing. Best way is to set up period of requesting, i.e. one company can do same kind of requests for example once in two years. It makes a company think twice about scaling ("do we requesting enough space for our grow?") and about conserving
Even if you can have a crystal ball that predicts your future addressing requirements for arbitrary amounts of time into the future, this still has a 1:1 ratio of end user organization to routing prefix and every flap of that prefix has to get propagated globally. This simply doesn't scale. Rgds, -drc
Even if you can have a crystal ball that predicts your future addressing requirements for arbitrary amounts of time into the future, this still has a 1:1 ratio of end user organization to routing prefix and every flap of that prefix has to get propagated globally.
Then we're stuck with a situation where on the one hand, RIPE membership is pressing for the continuation of a non-scalable addressing policy out of commercial necessity, but on the other, there are no real policy disincentives to discourage end-users from this harmful practice. This is quite an absurd situation, really. This policy inconsistency needs to be fixed urgently. And the most appropriate way of doing it is to apply both an initial and recurring charge to PI assignments. This is a reasonable system which will deal with not only the financial reality that IRRs cost money to run, but will also act as a much-needed disincentive to applying for PI space. Nick
David Conrad wrote:
You also can't scale PA when it ends. You only can allocate new one.
The difference, of course, is that PA (by definition) can be aggregated into a single announcement, thereby reducing the amount of information sloshing around the routing system. It is true that if an ISP runs out of PA prefixes to assign to their customers that they'll need to get another one and that additional prefix will need to be PI, but that is a single prefix that aggregates all the customers numbered out of that prefix. This is Routing Scalability 101.
Please, see the difference of just customers (who don't know anything about PI vs PA at all, using their ADSL connection and be happy) and those who need own routing policy and own IP space. You can't aggregate second one into single prefix by definition. Again, I don't even think about "portable IPs to any customer" at this stage of Internet evolution. May be a bit later? But not now. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Max, On Sep 20, 2006, at 4:40 AM, Max Tulyev wrote:
Again, I don't even think about "portable IPs to any customer" at this stage of Internet evolution. May be a bit later? But not now.
So what is the criteria between customers who should get PI and who shouldn't? Thanks, -drc
David Conrad wrote:
Max,
On Sep 20, 2006, at 4:40 AM, Max Tulyev wrote:
Again, I don't even think about "portable IPs to any customer" at this stage of Internet evolution. May be a bit later? But not now.
So what is the criteria between customers who should get PI and who shouldn't?
Multihoming. In some other rare cases - really large problems with renumbering (hosting provider with 10000 domains). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Simply, PI to network topological leaves doesn't scale.
On the contrary, PI *DOES* scale and it has scaled because there is no direct one-to-one connection between issuing a PI assignment and consuming a global routing table slot. Far more worrisome is the practice of issuing multiple non-aggregatable blocks to a single AS and the tendency of some ASes to use multiple global routing table slots for traffic engineering. Those things have greater impact on global routing table size than the number of new PI blocks. In addition, there is no consensus that the global routing table is becoming too big for providers to cope. If there was an imminent problem, then network operators would be meeting in public forums to define the scope of the problem and to agree on actions to mitigate the problem. If that were happening then RIPE could leverage the existence of this consortium of network operators to incorporate global routing table issues into its policies. But since this hypothetical consortium does not currently exist, RIPE can find nobody to take responsibility for global routing table impact and therefore cannot include global routing table size in its policies. --Michael Dillon
Hi, On Wed, Sep 20, 2006 at 10:17:32AM +0100, Michael.Dillon@btradianz.com wrote:
But since this hypothetical consortium does not currently exist, RIPE can find nobody to take responsibility for global routing table impact and therefore cannot include global routing table size in its policies.
Invalid conclusion. *We* are RIPE. *You* are part of RIPE. So of course the RIPE policies can consider routing table impact. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Invalid conclusion. *We* are RIPE. *You* are part of RIPE.
So of course the RIPE policies can consider routing table impact.
RIPE represents network operators from one of the 5 regions of the world which share the global routing table. How can RIPE reasonably deal with such a global issue unilaterally? Currently, the interdomain routing system requires a flat non-hierarchical architecture for the global routing table. Unless RIPE introduces some sort of routing model which involves a European routing table that carries more detail than the global routing table, then RIPE should not accept any responsibility at all for the use of global routing table slots. The decisions about the use of routing table slots are not made within RIPE. They are private decisions of private organizations outside of the RIPE terms of reference. --Michael Dillon
On Wed, 2006-09-20 at 11:51 +0100, Michael.Dillon@btradianz.com wrote:
RIPE represents network operators from one of the 5 regions of the world which share the global routing table. How can RIPE reasonably deal with such a global issue unilaterally?
RIPE is not an island and no matter how much we'd like to pretend otherwise, RIPE addressing policies cannot be meaningfully divorced from the population of routing table slots. You're free to agree or disagree with this, but the bottom line is that if RIPE changes its policies on PI assignment, this is likely to impact the number of announced PI prefixes, regardless of whether the announcements are accepted or not. Also, RIPE is not dealing with this unilaterally. It's dealing with the issue in its own area, which is what it's mandated to do by its members and charged to do by ICANN. If it makes policies in one particular area, these policies are not directly relevant in other parts of the world, unless other RIR areas in the world decide that they want to adopt similar policies. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
Michael, On Sep 20, 2006, at 2:17 AM, Michael.Dillon@btradianz.com wrote:
Simply, PI to network topological leaves doesn't scale.
On the contrary, PI *DOES* scale and it has scaled because there is no direct one-to-one connection between issuing a PI assignment and consuming a global routing table slot.
Yes, pedantically, if you don't insert a prefix into the routing system, it scales quite well. I'm not sure this distinction has much value though.
Those things have greater impact on global routing table size than the number of new PI blocks.
More specific announcement for TE may have a greater impact _today_ but given the pattern of liberalization of PI policies in all the RIRs, it isn't clear to me this will be the case in the future. What's worse is that more specifics can be filtered while still potentially providing routability (albeit perhaps sub-optimally) through the supernet. If you apply filters that affect PI prefixes, those prefixes are simply gone. Rgds, -drc
* Max Tulyev:
Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price.
Reality check, please. Market prices for PI space (excluding router setup etc.) are quite close to LIR setup fees.
Florian Weimer wrote:
Reality check, please. Market prices for PI space (excluding router setup etc.) are quite close to LIR setup fees.
Where??? Near me it is ~$300 for /24, ~$500 for /23, ~$700 for /22. AS included ;) It's not only my price, it is market there... -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
I have a question though, the proposal includes the notion of "major issue", perhaps this could be specified a bit more? Or is it clear how this would be interpreted by a hostmaster processing an application, that if the customer adds "I need to advertise this on the public internet" it will automatically be known that a at least a /24 is needed?
If the organization is simultaneously applying for an AS number or the organization already has an AS number, then we should consider routing to be a major issue if the organization says that it is. After all, the only purpose of having an AS number is to do routing. --Michael Dillon
On Tue, 2006-08-29 at 10:25 +0200, Filiz Yilmaz wrote:
PDP Number: 2006-05 PI Assignment Size
Dear Colleagues,
A new RIPE Policy has been proposed and is now available for discussion.
This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.
When should RIRs allocate v4 PI-blocks so small they won't be globally accepted? Such would in reality become small "private" blocks. For v6 the discussion is still open wrt the allocation of private (unannuced) addresses, but for v4 we should stick to rfc1918 and ask those who don't qualify for an allocation big enough to pursue de-aggregated PA-space which at least will be routed through its wider aggregate. The wording in the policy should instead reflect the need for consistence between the minimum size of allocated blocks and common filtering recommendations for the related IANA container-block (/8). //per -- Per Heldal - http://heldal.eml.cc/
Per Heldal wrote:
On Tue, 2006-08-29 at 10:25 +0200, Filiz Yilmaz wrote:
PDP Number: 2006-05 PI Assignment Size
Dear Colleagues,
A new RIPE Policy has been proposed and is now available for discussion.
This proposal suggests to have the minimum assignment size for PI assignments to be a /24 when routing is a major issue for a multihoming End User.
I still think that proposal is a completely inappropriate approach to take volatile(1) routing configuration criteria as (major) input for manufacturing address assignment policies. (1) volatile in the sense that a) (change in) filtering behaviour of ISPs is not consistent, nor under the control of the body having to agree on addressing policy, and b) as has been pointed out already, this behaviour might change "any time", rendering the policy broken again.
When should RIRs allocate v4 PI-blocks so small they won't be globally accepted? Such would in reality become small "private" blocks. For v6 the discussion is still open wrt the allocation of private (unannuced) addresses, but for v4 we should stick to rfc1918 and ask those who don't qualify for an allocation big enough to pursue de-aggregated PA-space which at least will be routed through its wider aggregate.
The wording in the policy should instead reflect the need for consistence between the minimum size of allocated blocks and common filtering recommendations for the related IANA container-block (/8).
//per
Another aspect of this proposal is that it would brake the equal opportunity approch opposite PA-Space - unless we raise the minimum block size for PA- assignments to /24 or whatever, too. Wilfried.
participants (26)
-
Andy Davidson -
bmanning＠vacation.karoshi.com -
David Conrad -
Dmitry Kiselev -
Erich Hohermuth -
Filiz Yilmaz -
Florian Weimer -
Garry Glendown -
Gennady Abramov -
Gert Doering -
Hank Nussbacher -
Jeroen Massar -
Joao Damas -
leo vegoda -
Marcus Gerdon -
Max Tulyev -
Michael.Dillon＠btradianz.com -
Mikael Abrahamsson -
Mike Hughes -
Nick Hilliard -
Oliver Bartels -
Per Heldal -
Randy Bush -
Roger Jorgensen -
Sascha Lenz -
Wilfried Woeber, UniVie/ACOnet