Just say *NO* to PI space -- or how to make it less destructive
Hi, I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity. Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis. We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix... .... Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through. If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance): 1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something. 2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters. 3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 04/20/06 at 4:48pm +0300, Pekka Savola <pekkas@netcore.fi> wrote:
Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through.
Very true. I'd even s/might/will/.
If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance):
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that. Now if you think ISPs should start charging end sites for the privilege of running BGP, that might fly. ISPs in the DFZ are bearing the costs of maintaining the extra routes*, so they can justify a per-route charge, and they actually have contracts with their customers, so they can collect. (* Yes, other end sites in the DFZ also bear those costs, but since they contribute routes to the table as well, and can sometimes switch to default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the bag" of routing table growth.)
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
With the current ARIN policy proposal, you'd get a /48, with a /44 reserved for growth. Would you advocate giving everyone a /44 up front instead? Or something else? I don't have too much preference here, FWIW.
3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks.
This is already a part of 2005-1, and has been a part (expressed or implied) of every other PI proposal I've seen. -Scott
On Thu, 20 Apr 2006, Scott Leibrand wrote:
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
I don't think that follows, but unless ARIN legal counsel or someone who is a real lawyer has made a statement here, I'm not sure how seriously to take this. Pointer to such official legal counsel would be appreciated. That is, ARIN has every right to require, for example, that everyone getting a prefix is (for instance) a member of ARIN, and charging for the membership should be OK. RIRs run on non-profit principle, but nothing precludes them from increasing the expenses, e.g., for donations to make the internet a better place, setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
With the current ARIN policy proposal, you'd get a /48, with a /44 reserved for growth. Would you advocate giving everyone a /44 up front instead? Or something else? I don't have too much preference here, FWIW.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On 20 Apr, 2006, at 16:18, Pekka Savola wrote:
On Thu, 20 Apr 2006, Scott Leibrand wrote:
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
Pekka, this doesn't sound like the right way to do policy, and yes, things that smell like "big guys get it, small guys don't" will be looked at suspiciously and rightly so. Criteria ought to be of a technical nature. Don't want PI: propose a feasible alternative that provides the same functionality under the current routing system, while looking for a better system.
RIRs run on non-profit principle, but nothing precludes them from increasing the expenses, e.g., for donations to make the internet a better place, setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
Now, *this* I do like a lot. RIRs sponsoring some research into something that directly affects the business they are chartered to do sounds right. It is one step further than the reporting pointing at the problem that Geoff is already doing at APNIC. Joao Damas ISC
On Thu, 20 Apr 2006, Joao Damas wrote:
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
Pekka, this doesn't sound like the right way to do policy, and yes, things that smell like "big guys get it, small guys don't" will be looked at suspiciously and rightly so. Criteria ought to be of a technical nature.
I'm assuming this is already in reference to, "PI should cost money" instead of "PI shouldn't be available, period"... Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff. AFAICS, whether or not a PI space would cost 0, 1000 or 5000 USD a year is NOT a barrier for entry. It's just *one* metric (you may be able to think of technical metrics that could imply the same, I can't) to say, "if you REALLY don't need this, it'd be nice if you seriously consider PA address space".
Don't want PI: propose a feasible alternative that provides the same functionality under the current routing system, while looking for a better system
Use PA addresses and Unique Local Addresses if you really think you need them. Push for shim6. Put some work on solving the remaining problems if there really are any that aren't caused by the desire to graze the commons for free. Maybe I should have snipped this quote, as this seems like a rathole which isn't worth exploring (again) here... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Hello; On Apr 20, 2006, at 11:28 AM, Pekka Savola wrote:
On Thu, 20 Apr 2006, Joao Damas wrote:
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
Pekka, this doesn't sound like the right way to do policy, and yes, things that smell like "big guys get it, small guys don't" will be looked at suspiciously and rightly so. Criteria ought to be of a technical nature.
I'm assuming this is already in reference to, "PI should cost money" instead of "PI shouldn't be available, period"...
Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff.
Yes, but I know many of people (including myself and basically all of my clients) who would regard a $ 5K tax as pretty onerous. You also run the risk of giving people the feeling that the system is weighted towards the large stakeholders. Now, I do not feel that way, but I hear from plenty of people who do, and it's hard to see how they wouldn't take it this way. Regards Marshall
AFAICS, whether or not a PI space would cost 0, 1000 or 5000 USD a year is NOT a barrier for entry. It's just *one* metric (you may be able to think of technical metrics that could imply the same, I can't) to say, "if you REALLY don't need this, it'd be nice if you seriously consider PA address space".
Don't want PI: propose a feasible alternative that provides the same functionality under the current routing system, while looking for a better system
Use PA addresses and Unique Local Addresses if you really think you need them. Push for shim6. Put some work on solving the remaining problems if there really are any that aren't caused by the desire to graze the commons for free.
Maybe I should have snipped this quote, as this seems like a rathole which isn't worth exploring (again) here...
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ PPML mailing list PPML@arin.net http://lists.arin.net/mailman/listinfo/ppml
Pekka, this doesn't sound like the right way to do policy, and yes, things that smell like "big guys get it, small guys don't" will be looked at suspiciously and rightly so. Criteria ought to be of a technical nature.
I'm assuming this is already in reference to, "PI should cost money" instead of "PI shouldn't be available, period"...
Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff.
Yes, but I know many of people (including myself and basically all of my clients) who would regard a $ 5K tax as pretty onerous.
You also run the risk of giving people the feeling that the system is weighted towards the large stakeholders. Now, I do not feel that way, but I hear from plenty of people who do, and it's hard to see how they wouldn't take it this way.
It doesn't make much sense to me for an RIR to charge large fees for v6 PI assignments, doing so is essentially behavior modification through taxation. On the other hand, it make perfect sense for anyone who wants their PI space advertised to pay their upstreams for the privilege, since there is a real cost in doing so. Also, it's naive to think that we won't ever have to pay for another round of router upgrades across the Internet; the only question is how long it can be delayed. Perhaps this time, though, it can be funded by the providers' customers, not the stockholders and creditors. Steve
On the other hand, it make perfect sense for anyone who wants their PI space advertised to pay their upstreams for the privilege, since there is a real cost in doing so.
Mmmm, and how is this going to guarantee that the PI space is accepted by third party networks? I'm aware that the two things are separate, paying to have your prefixes accepted by an upstream, and expecting them to be globally routable. But how is the average Joe Schmoe customer going to feel if they pay a premium to have their PI prefixes "accepted" by their ISP's upstreams, when they're not accepted by anyone else? Not convinced, Nick
On the other hand, it make perfect sense for anyone who wants their PI space advertised to pay their upstreams for the privilege, since there is a real cost in doing so.
Mmmm, and how is this going to guarantee that the PI space is accepted by third party networks?
As well as PA: nobody is guaranteeing nothing :) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
I don't think that follows, but unless ARIN legal counsel or someone who is a real lawyer has made a statement here, I'm not sure how seriously to take this. Pointer to such official legal counsel would be appreciated.
Those of us who have lived and worked in North America or the UK, have a general understanding of this because restraint of trade doctrine is a part of English common law which was then inherited by other countries such as Canada and the USA. However, European competition law is not based on the same principles and in the UK today, there are often conflicts between the doctrine of restraint of trade and European competition law. If you are interested in understanding this then start here http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx The important bit is the RULE OF REASON towards the bottom. If your English is advanced enough, then you could try reading legislation such as the Sherman Act, but you may find that lawyers like to use common words in uncommon ways. This illustrates the wisdom of the industry driven bottom-up policy development process that results in ARIN developing IP address policy in North America and RIPE doing the same job in Europe. There are different norms of society and of law in these different places. The people of North America would probably view your position as a SOCIALIST one and see that as a very negative thing. However, in Europe, people will tend to see your position as a SOCIALIST one and see that as a good thing. Because you are crossposting this thread to a global V6 list and to a RIPE mailing list, it seems to me that you feel there should be a single unitary global policy. However, that is contrary to the structure of the RIR system, contrary to NRO policy and contrary to the outcome of last autumns WSIS meetings. Policy proposal 2005-1 is an ARIN proposal that has worked its way through the ARIN policy process. We discussed it intensely at the recent ARIN meeting in Montreal and it was broadly accepted by the participants at that meeting. It is highly likely that it will become part of ARIN policy and ARIN *WILL* be issuing PI IPv6 blocks by the end of the year. You are welcome to register your disapproval, however so many people have worked to develop this reasonable compromise that I don't think you will be able to sway any of them.
RIRs run on non-profit principle, but nothing precludes them from increasing the expenses, e.g., for donations to make the internet a better place, setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
I'm not sure if research is within ARIN's scope, however even if it is, we cannot delay deployment of IPv6 merely because there is still a need for research. Throughout the deployment of IPv4 and the astronomical growth of the Internet, both research and commercial deployment happened simultaneously and the results brought major benefits to society, even if it did mean a lot of struggle with imperfections.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44).
I think you misunderstand ARIN's allocation algorithm here. The purpose of a reserved block is to allow an applicant to receive an increased allocation from the reserved block in order to be able to aggregate the new and old allocations. If the recipient of a /48 allocation applies for more and receieves the rest of their reserved /44 then they can announce a single /44 prefix instead of two /48 prefixes (or more). This minimizes the impact on the global routing table. The ARIN IPv4 allocation algorithm works the same way. --Michael Dillon
On Thu, 20 Apr 2006, Michael.Dillon@btradianz.com wrote:
I don't think that follows, but unless ARIN legal counsel or someone who is a real lawyer has made a statement here, I'm not sure how seriously to take this. Pointer to such official legal counsel would be appreciated. ... If you are interested in understanding this then start here http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx
This includes important gold nuggets such as ".. whether the practice complained of _unreasonably_ restrains competition", "The true test of legality is whether the restraint imposed is such as _merely regulates_ and perhaps thereby promotes competition ..." .. which imply that reasonable restraints may be OK (and many could count e.g., continued well-being of the common Internet routing system a reasonable thing), or that such acts may not necessarily be restrictive, but rather leveling the competion. But all of this is irrelevant, as I'm not interested in your or my arm-chair lawyering. I'm interested in reference to what ARIN legal counsel has said on this.
Because you are crossposting this thread to a global V6 list and to a RIPE mailing list, it seems to me that you feel there should be a single unitary global policy.
No, the discussion has been recently brought up at least on those lists, and it would seem unwise to repeat it on every list. Even if each region made its own policies, it might be much easier for everyone (IMHO) if the discussion was held on a common list, and then when the time comes, folks would each go to their own individual RIR to make their informed or uninformed decisions.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44).
I think you misunderstand ARIN's allocation algorithm here. The purpose of a reserved block is to allow an applicant to receive an increased allocation from the reserved block in order to be able to aggregate the new and old allocations. If the recipient of a /48 allocation applies for more and receieves the rest of their reserved /44 then they can announce a single /44 prefix instead of two /48 prefixes (or more). This minimizes the impact on the global routing table. The ARIN IPv4 allocation algorithm works the same way.
I understand the policy very well. If the above only were the case. The possible outcomes are (in an example case of expansion to /47): - the site advertises a 2001:db8:0::/47 - the site advertises a 2001:db8:0::/48 and 2001:db8:1::/48 - the site advertises a 2001:db8:0::/47 and one of /48's - the site advertises a 2001:db8:0::/47 and both of /48's Based on observations in v4 land, there are sites that specifically want to do something other than the first option, and I specifically want to preclude them from doing so. For almost every site, a /48 is enough. For those for whom it's not enough, they already want separable advertisements for TE purposes (e.g., multiple data centers), so they need either multiple /48's or tricks like above in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Thu, Apr 20, 2006 at 07:15:15PM +0300, Pekka Savola wrote:
Based on observations in v4 land, there are sites that specifically want to do something other than the first option, and I specifically want to preclude them from doing so.
For almost every site, a /48 is enough. For those for whom it's not enough, they already want separable advertisements for TE purposes (e.g., multiple data centers), so they need either multiple /48's or tricks like above in any case.
I think pekka already hinted at it, but people interested in this topic really should look at: http://www.iepg.org/march2006/BGP-2005.pdf for some analysis of a situation that could get worse. I think there's arguments both ways on this, but Geoff's talk was very interesting and enlightening. -- Tim/::1
If you are interested in understanding this then start here http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx
This includes important gold nuggets such as ".. whether the practice complained of _unreasonably_ restrains competition", "The true test of legality is whether the restraint imposed is such as _merely regulates_ and perhaps thereby promotes competition ..."
Yes, of course. All laws are like that, especially in a country like the USA which relies heavily on common-law and case-law precedents. People who live and work in the ARIN region tend to develop a gut feel for what is legal and what is not based on their experience in business and exposure to local media. I don't think it is productive to try and second guess on this list, what an American judge might decide.
No, the discussion has been recently brought up at least on those lists, and it would seem unwise to repeat it on every list. Even if each region made its own policies, it might be much easier for everyone (IMHO) if the discussion was held on a common list, and then when the time comes, folks would each go to their own individual RIR to make their informed or uninformed decisions.
On that, I disagree with you. That kind of centralised system defeats the bottom up nature of the existing RIRs.
Based on observations in v4 land, there are sites that specifically want to do something other than the first option, and I specifically want to preclude them from doing so.
It is probably not too late to suggest that the ARIN AC include the same "no deaggregation" language as was used for IPv6 LIRs. This was discussed tangentially at the meeting and I don't recall any of the speakers objecting to that. On the other hand, ARIN policy cannot restrict what two peers do between themselves. At this point in time, the global routing table is merely a convenient phrase used in routing discussions. There really is no such thing. Nobody manages the global routing table. There are no explicit agreements on what can or cannot be announced into the global routing table. And so on. If that were to change then your issues would be perfectly within scope. However, this would require the ARIN Board of Trustees to agree to undertake this activity. Interestingly enough, this does seem to be within ARIN's scope if you read items 2, 3, 4 and 6 of the purposes in the ARIN Articles of Incorporation. Assuming that there was to be an RIR function which produced guidelines for management of the global routing table, how would it operate and how would it ensure industry-wide consensus on those rules? --Michael Dillon
Thus spake "Pekka Savola" <pekkas@netcore.fi>
On Thu, 20 Apr 2006, Scott Leibrand wrote:
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
I think that the multihoming requirement will be enough to keep the number of assignments reasonable; if you look at the actual number of non-transit ASNs in the v4 table, it's not all that large. If we assume one PIv6 prefix per non-transit ASN, which is the goal, we're looking at under 10k routes from the ARIN region.
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
I don't think that follows, but unless ARIN legal counsel or someone who is a real lawyer has made a statement here, I'm not sure how seriously to take this. Pointer to such official legal counsel would be appreciated.
That is, ARIN has every right to require, for example, that everyone getting a prefix is (for instance) a member of ARIN, and charging for the membership should be OK.
I'd want a lawyer to sign off on it. You're talking about deliberately charging an excessive fee to make it more difficult for smaller companies to compete with larger ones. That has the appearance of an industry cartel creating artificial barriers to lock their smaller competitors out of the market, and the FTC generally doesn't like that. Then again, IANAL.
RIRs run on non-profit principle, but nothing precludes them from increasing the expenses, e.g., for donations to make the internet a better place,
That's an interesting thought, but siphoning off fees for other purposes (no matter how noble or popular) is a slippery slope. Let's keep the RIRs focused on what they were created for and on a cost-recovery basis, and members who want to donate to ISOC or other groups can do so.
setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
In theory, we already have a group tasked with that: the IETF. Are you proposing that RIRs start developing protocols outside the IETF? Or funding people to work full-time in the IETF on problems pertinent to RIRs? Again, this is a slippery slope and distracts from the RIRs' purpose. I definitely encourage the folks that are against PIv6 to work on better solutions, but IMHO the RIRs are not the correct vehicle or forum for that. ARIN is already treading on thin ice by rejecting the IETF's addressing plan.
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
With the current ARIN policy proposal, you'd get a /48, with a /44 reserved for growth. Would you advocate giving everyone a /44 up front instead? Or something else? I don't have too much preference here, FWIW.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44).
So instead of giving an org a /47, which _could_ be advertised as a single route, you'd prefer to give them two /48s, which _must_ be advertised as two routes? That seems to increase routing table pollution, not reduce it. Also, what's the point of reserving a /44, or worse multiple /44s, if we're only going to let people use a /48? That seems to defeat the purpose of having a reserved block. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
On Thu, 20 Apr 2006, Stephen Sprunk wrote:
I think that the multihoming requirement will be enough to keep the number of assignments reasonable; if you look at the actual number of non-transit ASNs in the v4 table, it's not all that large. If we assume one PIv6 prefix per non-transit ASN, which is the goal, we're looking at under 10k routes from the ARIN region.
(Actually, the number is somewhere between 15k and 20k but that's beside the point.) The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????" Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
That is, ARIN has every right to require, for example, that everyone getting a prefix is (for instance) a member of ARIN, and charging for the membership should be OK.
I'd want a lawyer to sign off on it. You're talking about deliberately charging an excessive fee to make it more difficult for smaller companies to compete with larger ones. That has the appearance of an industry cartel creating artificial barriers to lock their smaller competitors out of the market, and the FTC generally doesn't like that.
Come on, arguing that 1K or even 5K is an "excessive fee" for PI prefixes in the context of reliable multihoming setup and services provided seems a bit absurd. I'd agree that if the charge was 100K per year, this could be considered locking out smaller competitors, but (say) 1K is nothing -- that's less than 100 bucks a month! You might even consider a payment like 1K or 2K fair: small ISPs which get exactly the same resources have to pay such in their membership fees. Obviously the end-sites should pay at least the same if they consume the same resources..
setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
In theory, we already have a group tasked with that: the IETF. Are you proposing that RIRs start developing protocols outside the IETF? Or funding people to work full-time in the IETF on problems pertinent to RIRs? Again, this is a slippery slope and distracts from the RIRs' purpose.
I said 'research', not 'engineering'. The IETF isn't the right vessel for research, though IETF could maybe be consulted on it.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44).
So instead of giving an org a /47, which _could_ be advertised as a single route, you'd prefer to give them two /48s, which _must_ be advertised as two routes? That seems to increase routing table pollution, not reduce it.
Not necessarily. Doing so would hopefully ensure that it'll be *more* difficult to justify for more than a /48 especially if you have to pay for the extra too (hence less pollution). I.e., we'd need to figure out we have sufficiently strict criteria.
Also, what's the point of reserving a /44, or worse multiple /44s, if we're only going to let people use a /48? That seems to defeat the purpose of having a reserved block.
As I said, I wouldn't object to reserving a /44 under those conditions, but I wouldn't require reservation either. One reason for reserving is that we could have the option of changing the policy later if we become wiser (or dumber) and decide that maybe we'll want to be able to deal out aggregatable chunks after all, regardless of the more specific crap that's filling the routing tables right now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Pekka Savola Hello, A few words.
The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????"
The upper limit is infinite. There is no requirement to first request an AS number to get a PI prefix (in this region) or to even use the AS.
Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
It is cheaper to get redundancy than multihoming which is more or less the same thing. But they want multihoming, okay.
Come on, arguing that 1K or even 5K is an "excessive fee" for PI prefixes in the context of reliable multihoming setup and services provided seems a bit absurd. I'd agree that if the charge was 100K per year, this could be considered locking out smaller competitors, but (say) 1K is nothing -- that's less than 100 bucks a month!
I think the fee should be the same as a normal LIR. I see no reason not to. Ah ok. Let's decrease it by €25 due to database storage and processing applications when the AW is not large enough.
You might even consider a payment like 1K or 2K fair: small ISPs which get exactly the same resources have to pay such in their membership fees. Obviously the end-sites should pay at least the same if they consume the same resources..
Agreed. And the size of the prefix shouldn't matter as long as it is higher than the recommended(?) /48 filter limit. Complicated policies are a pain and makes people ignore/forget/misunderstand them. Yes it will potentially create a trillion prefixes in the table, but you are free to ignore them should someone carve their /19 into /48s - just like you are with IPv4 today. j
Thus spake "Pekka Savola" <pekkas@netcore.fi>
On Thu, 20 Apr 2006, Stephen Sprunk wrote:
I think that the multihoming requirement will be enough to keep the number of assignments reasonable; if you look at the actual number of non-transit ASNs in the v4 table, it's not all that large. If we assume one PIv6 prefix per non-transit ASN, which is the goal, we're looking at under 10k routes from the ARIN region.
(Actually, the number is somewhere between 15k and 20k but that's beside the point.)
ARIN Region origin ASes present in the Internet Routing Table: 10637 ... ARIN Region transit ASes present in the Internet Routing Table: 986 To me, that says we have 9651 non-transit ASes in ARIN-land today. Now, if every one of those ASes got an assignment under 2005-1, we'd kick up the size of the v6 routing table to 14 times its current size -- but it'd still be only 1/18th of the current v4 table. Where's the problem?
The upper limit is around the number of AS numbers, and if it's expanded to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 64K folks playing around at DFZ isn't enough??? we want 4B instead...????"
There's at least one router vendor that claims their box can do 1M routes today; Moore's Law says in 18 years they'll be able to do 4B ASes with one prefix each. I'm pretty confident we won't run into that particular limit before we run out of networks to multihome, at least not with the proposal on the table today.
Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
That loophole in the definition of multihoming needs to be fixed. For that matter, ARIN told me offlist that two IP-in-IP tunnels over a single physical link counts as multihoming... Sheesh. OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and nobody is taking ARIN up on it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today?
setting a foundation for multihoming research to actually SOLVE this problem, etc.etc.
In theory, we already have a group tasked with that: the IETF. Are you proposing that RIRs start developing protocols outside the IETF? Or funding people to work full-time in the IETF on problems pertinent to RIRs? Again, this is a slippery slope and distracts from the RIRs' purpose.
I said 'research', not 'engineering'. The IETF isn't the right vessel for research, though IETF could maybe be consulted on it.
s/IETF/IRTF/ then. The RRG is expecting to have results sometime between 2007 and 2011. That's probably sufficient, if they actually deliver something useful. Still, the RIRs' job is not research, it is stewardship of address space and serving its members.
I wouldn't object to reserving a /44 just in case, but make no provisions (at this point) for applying more. If someone needs more than /48, it needs to justify another one, and get a separate /48 (with its own reserved /44).
So instead of giving an org a /47, which _could_ be advertised as a single route, you'd prefer to give them two /48s, which _must_ be advertised as two routes? That seems to increase routing table pollution, not reduce it.
Not necessarily. Doing so would hopefully ensure that it'll be *more* difficult to justify for more than a /48 especially if you have to pay for the extra too (hence less pollution). I.e., we'd need to figure out we have sufficiently strict criteria.
That just seems backwards to me. If a site _can_ justify more than a /48 under whatever the policy is, why would we want to assign two separate blocks that can't be aggregated into a single route?
Also, what's the point of reserving a /44, or worse multiple /44s, if we're only going to let people use a /48? That seems to defeat the purpose of having a reserved block.
As I said, I wouldn't object to reserving a /44 under those conditions, but I wouldn't require reservation either. One reason for reserving is that we could have the option of changing the policy later if we become wiser (or dumber) and decide that maybe we'll want to be able to deal out aggregatable chunks after all, regardless of the more specific crap that's filling the routing tables right now.
If we're going to reserve, we ought to assign supernets within that block as justified by the org. If they deaggregate, so be it, but at least there's the chance they won't. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
At 03:39 21/04/2006, Stephen Sprunk wrote:
ARIN Region origin ASes present in the Internet Routing Table: 10637 ... ARIN Region transit ASes present in the Internet Routing Table: 986
To me, that says we have 9651 non-transit ASes in ARIN-land today.
Now, if every one of those ASes got an assignment under 2005-1, we'd kick up the size of the v6 routing table to 14 times its current size -- but it'd still be only 1/18th of the current v4 table. Where's the problem?
[...]
OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and nobody is taking ARIN up on it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today?
This is perhaps the most pertinent question to have been asked during this thread and I'm not sure I saw any answer to it. So I'll ask it again. What is the evidence that using v4's PI policy for v6 would lead to a land rush of catastrophic proportions and the routing table becoming huge? All I've seen so far is hand-waving doomsayers. Remember that to get PI space at all you have to know what you are doing, and you have to justify the usage. And the process takes a certain time. All of these would tend to discourage the casual enquirer. -- Tim
On Tue, 2006-04-25 at 10:15 +0100, Tim Streater wrote:
At 03:39 21/04/2006, Stephen Sprunk wrote: [..]
OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two pipes or tunnels), and there's not all that many companies doing it. It's not growing much either. The doors are already wide open for a land rush and >>nobody is taking ARIN up on it. Why does everyone assume it'll happen with v6 if it's not happening with v4, which _is_ useful today?
This is perhaps the most pertinent question to have been asked during this thread and I'm not sure I saw any answer to it. So I'll ask it again. What is the evidence that using v4's PI policy for v6 would lead to a land rush of catastrophic proportions and the routing table becoming huge? All I've seen so far is hand-waving doomsayers.
There is no evidence, but it might just happen ;) Maybe not today, but maybe in a couple of years. IPv6 is intended to be there for the coming decades, not for tomorrow.
Remember that to get PI space at all you have to know what you are doing, and you have to justify the usage. And the process takes a certain time. All of these would tend to discourage the casual enquirer.
This is indeed the only limit for both IPv6 PA and the new to be coming PI space: you need to know what you are doing. Thus upto the time that somebody writes up a "HOWTO: Multihoming at home" document it should not cause much issues. That said, when/if a landrush would break out, people are still in control of their own routers and it will become very easy to start filtering certain small prefixes. This happened also in IPv4 (try announcing a /28 or so ;). At that point, people who have the cash can keep on doing it that way, other folks will have to resort to different methods like shim6/hip/sctp and a number of other proposals. In the end one will still need "PI" space at most sites anyway. As it is the sole method of making sure that one can stick IP addresses in certain important places like firewall rules and DNS without ever having to think about it again or having to remember that you stuck them there. This is where the above methods come in, they will make the packet, while traveling over the internet be the upstreams src/dst, while being "PI" on the edges. This solves all the issues at hand. For the time being though people can happily use IPv6 PI space in the way they are 'used' to in IPv4. This gives enough time for the new methods to become crystal clear and cover all the known problemspaces so that end-sites can use them happily ever after. Greets, Jeroen
On Thu, 20 Apr 2006 18:28:41 +0300, you wrote:
Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff.
On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote:
Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
Could you finally make up your mind? First, your argument was that multihoming is expensive anyway, so shelling out another couple thousand of EUR/USD/whatever doesn't make a difference - just to keep the clueless bottom-feeders out. Now you say it's totally cheap to multihome. You're contradicting yourself. If you want to contain /senseless/ DFZ pollution, start with the ISPs. Just take a look at CIDR report. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Fri, 21 Apr 2006, Daniel Roesen wrote:
On Thu, 20 Apr 2006 18:28:41 +0300, you wrote:
Larger end-sites already have 10-20k+ annual budget (most have much, much larger than that): caused by CAPEX by getting at least two routers, OPEX by paying to multiple ISPs for fibers, transit, etc. and salaries of network engineering staff.
On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote:
Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
Could you finally make up your mind? First, your argument was that multihoming is expensive anyway, so shelling out another couple thousand of EUR/USD/whatever doesn't make a difference - just to keep the clueless bottom-feeders out. Now you say it's totally cheap to multihome.
You're contradicting yourself.
You took the comments out of context. The former describes that _real_ multihoming is expensive, the latter describes that you could obtain "multihoming" very easily. The point is that we definitely shouldn't want to assign PI to the organizations in the latter category. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Thus spake "Pekka Savola" <pekkas@netcore.fi>
On Fri, 21 Apr 2006, Daniel Roesen wrote:
On Thu, Apr 20, 2006 at 11:44:42PM +0300, Pekka Savola wrote:
Remember, it's easy and cheap to have a multihoming setup with two DSL lines...
ARIN has replied to me privately that two IPv6 tunnels over the same physical link count as "multihoming"; another PPML poster has told me privately he's actually gotten an ASN that way. IMHO this needs to be corrected, but it doesn't appear to be abused except out of novelty, so it's not a dire emergency.
Could you finally make up your mind? First, your argument was that multihoming is expensive anyway, so shelling out another couple thousand of EUR/USD/whatever doesn't make a difference - just to keep the clueless bottom-feeders out. Now you say it's totally cheap to multihome.
You're contradicting yourself.
You took the comments out of context. The former describes that _real_ multihoming is expensive, the latter describes that you could obtain "multihoming" very easily. The point is that we definitely shouldn't want to assign PI to the organizations in the latter category.
My reading of the proposal is that it would allow anyone who is multihomed to get a PIv6 /48 if they can demonstrate the ability to utilize 256 addresses immediately and 512 addresses within one year, or 1024 and 2048 addresses, respectively, if not multihomed. The address counts appear to be reasonable at first blush. They're high enough to stop residential and SOHO users, but low enough for nearly any shop with BGP clue to get a block. Do remember that only a few hundred direct assignments have been made under the PIv4 policy, so apparently it's not _too_ low or we'd have seen a land rush already. As far as fees, if the org already has IPv4 space of some sort, the PIv6 assignment will presumably be free through 31 Dec 07 like PAv6 assignments and USD1250/yr after that. The idea of charging thousands of dollars more to discourage PIv6 applications is not in line with existing fee schedules and rather pointless since folks can apparently claim to be LIRs without much difficulty and pay USD2250/yr for a /32. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin
"Stephen Sprunk" <stephen@sprunk.org> writes:
ARIN has replied to me privately that two IPv6 tunnels over the same physical link count as "multihoming"; another PPML poster has told me privately he's actually gotten an ASN that way.
IMHO this needs to be corrected, but it doesn't appear to be abused except out of novelty, so it's not a dire emergency.
Now, this is an interesting one. Where would you draw the line for diversity of connections being truly "multihomed"? Here are a few scenarios for your consideration: Commodity MPLS from a third party provider (yes, i know this doesn't exist yet) with one pipe going to two ISPs. Commodity Frame Relay or ATM with two DAFs entering the facility, but an inspection of the DLRs for the PVCs shows that they both traverse the same switch. Two SONET connections that are groomed onto the same OC48. Two SONET connections that are physically distinct but enter the customer facility via the same conduit. I'm not so sure that I agree with your implication that justifying an ASN on the basis of two tunnels is "abuse". It might be "poor engineering", "unwise", or "certainly something I would never do", but ARIN policy is intended to apply good stewardship principles, not coerce people's business or engineering plans. We agree that the current level of unconventional registration is likely low. I don't agree that there's anything to "fix" here. By the way, the other way you can justify an ASN is to have a "unique routing policy". What that constitutes is left as an exercise to the reader, but I'm sure that a session in the bar in St. Louis could come up with some really freaky scenarios. Current policy is OK by me. It will be even more OK after 32-bit ASNs are the norm. ---Rob
Commodity Frame Relay or ATM with two DAFs entering the facility, but an inspection of the DLRs for the PVCs shows that they both traverse the same switch.
Two SONET connections that are groomed onto the same OC48.
We know that separacy of circuits is subject to change due to the widespread use of switches (DACS, ATM, Ethernet) and the widespread telecom practice of grooming customer circuits over time. It is hard work to ensure that true separacy exists when it is needed to meet customer contract conditions. Given this, I think it would be unwise to specify the degree of separacy in an ARIN policy. It would be almost impossible to enforce such a provision even if you restrict it to new applications. And even then, anyone can comply to get their ASN and PI block, then go back to the pair of IPv6 tunnels for the long haul. ARIN policy has always had to strike a balance. We are not lawmakers or law enforcers. --Michael Dillon
On Apr 21, 2006, at 9:55 AM, Michael.Dillon@btradianz.com wrote:
Commodity Frame Relay or ATM with two DAFs entering the facility, but an inspection of the DLRs for the PVCs shows that they both traverse the same switch.
Two SONET connections that are groomed onto the same OC48.
We know that separacy of circuits is subject to change due to the widespread use of switches (DACS, ATM, Ethernet) and the widespread telecom practice of grooming customer circuits over time. It is hard work to ensure that true separacy exists when it is needed to meet customer contract conditions.
Empirically, I would say that it is impossible to be sure. I have heard too many stories of a {fire, collision, back hoe, etc.} taking down two circuits that were supposed to be geographically separated, or circuits that weren't supposed to be going that way at all. If the people charged with doing this can't be sure, how can ARIN ?
Given this, I think it would be unwise to specify the degree of separacy in an ARIN policy. It would be almost impossible to enforce such a provision even if you restrict it to new applications. And even then, anyone can comply to get their ASN and PI block, then go back to the pair of IPv6 tunnels for the long haul.
ARIN policy has always had to strike a balance. We are not lawmakers or law enforcers.
I would agree. Regards Marshall
--Michael Dillon
_______________________________________________ PPML mailing list PPML@arin.net http://lists.arin.net/mailman/listinfo/ppml
As far as fees, if the org already has IPv4 space of some sort, the PIv6 assignment will presumably be free through 31 Dec 07 like PAv6 assignments and USD1250/yr after that. The idea of charging thousands of dollars more to discourage PIv6 applications is not in line with existing fee schedules and rather pointless since folks can apparently claim to be LIRs without much difficulty and pay USD2250/yr for a /32.
Only if the ORG is an ARIN member. If they are not a member, there is no waiver. Membership is $500/year if you are not an ISP subscriber member (which involves paying significantly more for your allocation/assignment unless you are a v6-only ISP). Owen -- If it wasn't crypto-signed, it probably didn't come from me.
-----Original Message----- From: Scott Leibrand [mailto:sleibrand@internap.com] Sent: Thursday, April 20, 2006 7:10 AM To: Pekka Savola Cc: ppml@arin.net; address-policy-wg@ripe.net; global-v6@lists.apnic.net Subject: Re: [ppml] Just say *NO* to PI space -- or how to make it lessdestructive
On 04/20/06 at 4:48pm +0300, Pekka Savola <pekkas@netcore.fi> wrote:
Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through.
Very true. I'd even s/might/will/.
If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance):
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
As has been discussed at ARIN, this is a good way to get the government to declare the RIR a monopoly engaging in anticompetitive behavior. I for one don't want that.
Now if you think ISPs should start charging end sites for the
Scott Good points. I might also ask folks to think back to the mid-nineties when the v6 designs were initiated. In 95 few businesses considered their network links to be "business critical", we couldn't have known that the corporate world would expect network reliability of 5 9's as a baseline today. Nor could we have guessed even in 2000 that our network reliability and outage recovery plans would be part our Sarbanes-Oxley audits. What I can tell you now is that because of these fundamental changes in business globally, the deployment model we envisioned in the mid-nineties won't work for business today. -There is simply no way that large corporations would sign up with a "single provider" for their IP addresses. The network is now the life blood of business and I don't know of any business executive that would permit themselves to be tied to a single supplier for something so critical to their bottom line. -Likewise, multi-homing to business is now a de-facto network expectation of most large corporations. As I said, they expect to deploy regional/national/global networks that have seamless connectivity with their sites and 5 9's or better of reliability. -I'm not even sure if a single service provider for this level of business criticality would pass the Sarbanes-Oxley audits. Business, in the post Enron environment, has a level of responsibility to their shareholders that they never could have envisioned a decade ago. In the decade it has taken us to be ready to deploy IP-v6, the world we based many of the deployment concepts of IP-v6 on has changed radically. We need to find a way to accommodate these changes in the relationship of the network to business; PI space is the only concept that I have seen so far that will provide business with the service model they now need. I'm virtually certain that most large and/or international corporations won't deploy IP-v6 unless they can make the service model fit their business needs. Take care Terry privilege
of running BGP, that might fly. ISPs in the DFZ are bearing the costs of maintaining the extra routes*, so they can justify a per-route charge, and they actually have contracts with their customers, so they can
collect. > (* Yes, other end sites in the DFZ also bear those costs, but since they > contribute routes to the table as well, and can sometimes switch to > default-only BGP, I'd argue that DFZ ISPs are the ones stuck "holding the > bag" of routing table growth.) > > > 2. one-size-fits-all assignments, period. You get a /48 or /32 (I > > don't have much preference here), but you must not be able to justify > > for larger space. This is to avoid the organization from getting a > > larger block and chopping it into smaller pieces and polluting the > > global routing table with more specifics which would get past prefix > > length filters. > > With the current ARIN policy proposal, you'd get a /48, with a /44 > reserved for growth. Would you advocate giving everyone a /44 up front > instead? Or something else? I don't have too much preference here, FWIW. > > > 3. assignments from a separate address block, set aside for PI. To > > ease strict "assignment-size only" filtering of these blocks. > > This is already a part of 2005-1, and has been a part (expressed or > implied) of every other PI proposal I've seen. > > -Scott > _______________________________________________ > PPML mailing list > PPML@arin.net > http://lists.arin.net/mailman/listinfo/ppml
Hi Pekka. Totally agree with you there. At the moment as we have PI with IPv4, and I'll guess there will be lot's of fuzz dropping It. On the other hand. If PI allocations were no more, then the same people you nag about here would try to become their own ASN:s. And the percentage of peers running on cheap 'o pc-boxes would quite possibly increase. Resulting in that the problem with flapping routes would probably remain, or even get worse. So the problem is really. How do we regulate PI to only be an accepted solution for extreme cases? And still have a fair policy to those who really needs this feature. Best regards. --Dennis Lundström GippNET Pekka Savola wrote:
Hi,
I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity.
Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis.
We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix...
....
Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through.
If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance):
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks.
Hi! Please, somebody, explain me The Big Problem! How routing table size on borders really affects the Internet? But please tell me about REAL routers and REAL situation. I can't see the differense between 10 path static routing and 190000 full view BGP even on old-like-dinosaurus-bones Cisco 3660. What I am doing wrong?
Hi Pekka. Totally agree with you there. At the moment as we have PI with IPv4, and I'll guess there will be lot's of fuzz dropping It. On the other hand. If PI allocations were no more, then the same people you nag about here would try to become their own ASN:s. And the percentage of peers running on cheap 'o pc-boxes would quite possibly increase. Resulting in that the problem with flapping routes would probably remain, or even get worse.
So the problem is really. How do we regulate PI to only be an accepted solution for extreme cases? And still have a fair policy to those who really needs this feature.
Best regards.
--Dennis Lundström GippNET
Pekka Savola wrote:
Hi,
I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity.
Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis.
We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix...
....
Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through.
If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance):
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks.
Hi, I can understand well your wish to glue client to your company with many different things, such as IP addresses (like non-portable phone numbers). But be honest - routing table size is _NOT_ a technical problem. It is an puffed up management "problem" aimed to take out users' ability to choise connectivity provider(s). Now routing table for IPv4 is near 190000 prefixes. And so what? Where is the problem?
Hi,
I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity.
Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis.
We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix...
....
Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through.
If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance):
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks.
-- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)
On Thu, Apr 20, 2006 at 04:48:30PM +0300, Pekka Savola wrote:
I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity. Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis. We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix...
So there shouldn't be PI for ISPs either, I guess. Only to Peering points (one per RIR). Would make the routing table so much cleaner. Completely impractical? Why is it possible for end sites then?
Now, from practical point of view, it seems there is strong "need" for PI, and it might be a PI policy of some kind might actually get through.
I strongly hope so.
If so, the policy should be such that it minimizes the bad effects of PI and encourages people to use other solutions if those are viable for them (unfortunately, the only way to achieve that appears to be $$$$), in particular (in the rough order of importance):
1. Each assignment must be accompanied by a recurring fee (at least 1000-2000 USD/EUR a year, preferably 5000+). This is peanuts (compared to other costs) to anyone who actually needs this multihoming solution. However, this ensures at least some minimum usage barrier ("those who don't really need this can use different multihoming solutions"), and recovery of the resources back to RIR after the company has gone bankrupt or no longer needs the addresses. If you don't know where to put the extra money, donate it to ISOC or something.
Where does this money go? Do you really want an Sub-PI-sales-market popping up? There will be startups buying a /32 and then selling /48s and /64s for a discount rate. There will be demand for anyone to route these nets.
2. one-size-fits-all assignments, period. You get a /48 or /32 (I don't have much preference here), but you must not be able to justify for larger space. This is to avoid the organization from getting a larger block and chopping it into smaller pieces and polluting the global routing table with more specifics which would get past prefix length filters.
This will also happen with /48 and /32. I am convinced the only solution to avoid this is only handing out /128s. Everything else will be taken apart.
3. assignments from a separate address block, set aside for PI. To ease strict "assignment-size only" filtering of these blocks.
Won't take long until the first ISPs fall. And then more and more will have to. There is no strong community, apart from those customers with lots-o-money. Nils -- Will trade links for food. [geklaut bei www.userfriendly.org]
So there shouldn't be PI for ISPs either, I guess. Only to Peering points (one per RIR). Would make the routing table so much cleaner. Completely impractical? Why is it possible for end sites then?
Now that is a very interesting suggestion. If you assume that multiple peering points in a single city have rich and cheap interconnection, you could extend this idea to one prefix per city with a population greater than 100,000. There are about 5000 such cities in the world so we are talking about 5000 prefixes. Of course, each of these cities serves a larger surrounding area with various services and such services often reach across national borders. For instance, the inhabitants of Kehl and Offenburg in Germany are likely to use services in Strasbourg, France such as the Opera du Rhin, shopping, etc. If you consider these large cities as centres of gravity for the surrounding area, then these 5000 cities cover almost all of the populated surface of the Earth. What could we do with 5000 such routes in the global routing table? Well, for one thing, we could offer an almost unlimited number of PI IPv6 address blocks to ever business or organization that feels the need to multihome in order to secure the separacy plus resiliency that need in their network connections. All of those PI blocks would be invisible in 4999 of the world's cities because those cities will only see the single city prefix. We then have solved the routing table scaling problem by dividing and conquering. There still could be some localised issues in some cities, but it is much simpler for a group of local ISPs to sort out a local issue than it is for everybody in the world to agree on the one true routing solution. The best part of this solution is that it requires no protocol changes, no new code in routers, and works with all existing IPv6 technology. It can be implemented entirely by changing RIR allocation rules, and ISP business practices. This is not a "flag day" situation either. There is no need to stop issuing and using provider aggregatable addresses. These new geo-topo aggregatable addresses can coexist in the same network. Some ISPs will choose to only assign one kind of addresses, either classic PA or new geo-topo addresses. Others will use both and use the newer ones to provide new services. The only area where business practices needs to change is inside a single city aggregate where the ISPs inside that aggregate have to agree on how to exchange traffic and how to deal with the hot-potato nature of geo-topo routing. Each city is free to come up with its own variation on this as long as they do not deaggregate the city aggregate address block outside of bilateral peering agreements. In other words, ISPs in London will see only a single route to all of the geo-topo space in Paris unless they have specific bilateral agreements with Paris ISPs. Remember we have reserved 7/8ths of the IPv6 address space in order to be able to implement these types of new addressing schemes. The main problem to be solved in order to deploy this, other than general agreement on the scheme, is how to size each of the 5000 city aggregate blocks. Geographers and economists would likely find this easy work, but we have to make contact with them, explain the problem, and ask for their analyses.
Won't take long until the first ISPs fall. And then more and more will have to. There is no strong community, apart from those customers with lots-o-money.
Most businesses only survive and thrive because they serve their customers well. Any ISP that expects to have a strong future must understand the needs of their customer base and then organize their company resources to serve those customers. This means that ISPs who see this as a battle of the PROVIDERS (with PA addresses) against the END USERS (with subnets assigned from PA blocks) are doomed. Providers have to look at this problem from the end user point of view and then find some solution that meets the end user needs while at the same time offering the ability for the provider to continue providing valuable services. In general, as you point out, these situations are like a steamroller and end user demand will win out in the end. However, we can avoid a period of chaos and instability if the providers take the lead and manage an orderly transition to the new network order. --Michael Dillon
On Fri, 21 Apr 2006 Michael.Dillon@btradianz.com wrote: great idea, finaly others that also have thought baout it... however, yeah it's a great change of the way Internet are and exist, and work... but it's doable. Guess the ISP just hate the idea tho... <snip>
Now that is a very interesting suggestion. If you assume that multiple peering points in a single city have rich and cheap interconnection, you could extend this idea to one prefix per city with a population greater than 100,000. There are about 5000 such cities in the world so we are talking about 5000 prefixes. Of course, each of these cities serves a larger surrounding area with various services and such services often reach across national borders. For instance, the inhabitants of Kehl and Offenburg in Germany are likely to use services in Strasbourg, France such as the Opera du Rhin, shopping, etc.
If you consider these large cities as centres of gravity for the surrounding area, then these 5000 cities cover almost all of the populated surface of the Earth. What could we do with 5000 such routes in the global routing table?
Well, for one thing, we could offer an almost unlimited number of PI IPv6 address blocks to ever business or organization that feels the need to multihome in order to secure the separacy plus resiliency that need in their network connections. All of those PI blocks would be invisible in 4999 of the world's cities because those cities will only see the single city prefix. We then have solved the routing table scaling problem by dividing and conquering. There still could be some localised issues in some cities, but it is much simpler for a group of local ISPs to sort out a local issue than it is for everybody in the world to agree on the one true routing solution.
The best part of this solution is that it requires no protocol changes, no new code in routers, and works with all existing IPv6 technology. It can be implemented entirely by changing RIR allocation rules, and ISP business practices. This is not a "flag day" situation either. There is no need to stop issuing and using provider aggregatable addresses. These new geo-topo aggregatable addresses can coexist in the same network. Some ISPs will choose to only assign one kind of addresses, either classic PA or new geo-topo addresses. Others will use both and use the newer ones to provide new services.
The only area where business practices needs to change is inside a single city aggregate where the ISPs inside that aggregate have to agree on how to exchange traffic and how to deal with the hot-potato nature of geo-topo routing. Each city is free to come up with its own variation on this as long as they do not deaggregate the city aggregate address block outside of bilateral peering agreements. In other words, ISPs in London will see only a single route to all of the geo-topo space in Paris unless they have specific bilateral agreements with Paris ISPs.
Remember we have reserved 7/8ths of the IPv6 address space in order to be able to implement these types of new addressing schemes. The main problem to be solved in order to deploy this, other than general agreement on the scheme, is how to size each of the 5000 city aggregate blocks. Geographers and economists would likely find this easy work, but we have to make contact with them, explain the problem, and ask for their analyses.
Won't take long until the first ISPs fall. And then more and more will have to. There is no strong community, apart from those customers with lots-o-money.
Most businesses only survive and thrive because they serve their customers well. Any ISP that expects to have a strong future must understand the needs of their customer base and then organize their company resources to serve those customers. This means that ISPs who see this as a battle of the PROVIDERS (with PA addresses) against the END USERS (with subnets assigned from PA blocks) are doomed. Providers have to look at this problem from the end user point of view and then find some solution that meets the end user needs while at the same time offering the ability for the provider to continue providing valuable services.
In general, as you point out, these situations are like a steamroller and end user demand will win out in the end. However, we can avoid a period of chaos and instability if the providers take the lead and manage an orderly transition to the new network order.
--Michael Dillon
-- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
I think this idea is no better than standard redundancy (multiple lines to the same ISP). Actually, I think it is worse since it is required of you to either stay in the city or stretch a long fibre to it should you move all or some of your stuff to another. Companies will try to do the latter because they don't want to change their IP. There are three types of PI-holders today a.f.a.i.k.: * The ones that just don't want to change IP-address and never use more than 1 ISP anyway. They don't have an AS number. * Same as above, but they have multiple lines to the ISP (redundancy). * Enterprises with "real" need of multi-homing having multiple uplinks to multiple ISPs and their own AS number. Couldn't the companies that _need_ PI multi-homing for redundancy reasons, these enterprises, create an ISP and get their "multi-homing" there instead? Can't be too hard filling in a ltd. application. I wouldn't be surprised if several enterprises have done it that way already. Since the stocks are owned by the enterprise (and perhaps a few others), being afraid of so-called bankruptcy is void. At least it is easier than getting IPv6 PI today. I believe the issue with keeping your IP-address when changing ISP is another problem. First of all, it is bad network setup to have such a requirement but there is a long way to avoid this with some of todays technology. Secondly, everybody should be able to keep their IP-address if they want (DNS is obviously not good enough). Not just PI-holders. j -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Roger Jorgensen Sent: 22. april 2006 12:34 To: Michael.Dillon@btradianz.com Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Just say *NO* to PI space -- or how to make it lessdestructive On Fri, 21 Apr 2006 Michael.Dillon@btradianz.com wrote: great idea, finaly others that also have thought baout it... however, yeah it's a great change of the way Internet are and exist, and work... but it's doable. Guess the ISP just hate the idea tho... <snip>
Now that is a very interesting suggestion. If you assume that multiple peering points in a single city have rich and cheap interconnection, you could extend this idea to one prefix per city with a population greater than 100,000. There are about 5000 such cities in the world so we are talking about 5000 prefixes. Of course, each of these cities serves a larger surrounding area with various services and such services often reach across national borders. For instance, the inhabitants of Kehl and Offenburg in Germany are likely to use services in Strasbourg, France such as the Opera du Rhin, shopping, etc.
If you consider these large cities as centres of gravity for the surrounding area, then these 5000 cities cover almost all of the populated surface of the Earth. What could we do with 5000 such routes in the global routing table?
Well, for one thing, we could offer an almost unlimited number of PI IPv6 address blocks to ever business or organization that feels the need to multihome in order to secure the separacy plus resiliency that need in their network connections. All of those PI blocks would be invisible in 4999 of the world's cities because those cities will only see the single city prefix. We then have solved the routing table scaling problem by dividing and conquering. There still could be some localised issues in some cities, but it is much simpler for a group of local ISPs to sort out a local issue than it is for everybody in the world to agree on the one true routing solution.
The best part of this solution is that it requires no protocol changes, no new code in routers, and works with all existing IPv6 technology. It can be implemented entirely by changing RIR allocation rules, and ISP business practices. This is not a "flag day" situation either. There is no need to stop issuing and using provider aggregatable addresses. These new geo-topo aggregatable addresses can coexist in the same network. Some ISPs will choose to only assign one kind of addresses, either classic PA or new geo-topo addresses. Others will use both and use the newer ones to provide new services.
The only area where business practices needs to change is inside a single city aggregate where the ISPs inside that aggregate have to agree on how to exchange traffic and how to deal with the hot-potato nature of geo-topo routing. Each city is free to come up with its own variation on this as long as they do not deaggregate the city aggregate address block outside of bilateral peering agreements. In other words, ISPs in London will see only a single route to all of the geo-topo space in Paris unless they have specific bilateral agreements with Paris ISPs.
Remember we have reserved 7/8ths of the IPv6 address space in order to be able to implement these types of new addressing schemes. The main problem to be solved in order to deploy this, other than general agreement on the scheme, is how to size each of the 5000 city aggregate blocks. Geographers and economists would likely find this easy work, but we have to make contact with them, explain the problem, and ask for their analyses.
Won't take long until the first ISPs fall. And then more and more will have to. There is no strong community, apart from those customers with lots-o-money.
Most businesses only survive and thrive because they serve their customers well. Any ISP that expects to have a strong future must understand the needs of their customer base and then organize their company resources to serve those customers. This means that ISPs who see this as a battle of the PROVIDERS (with PA addresses) against the END USERS (with subnets assigned from PA blocks) are doomed. Providers have to look at this problem from the end user point of view and then find some solution that meets the end user needs while at the same time offering the ability for the provider to continue providing valuable services.
In general, as you point out, these situations are like a steamroller and end user demand will win out in the end. However, we can avoid a period of chaos and instability if the providers take the lead and manage an orderly transition to the new network order.
--Michael Dillon
-- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Hi, On Sat, Apr 22, 2006 at 03:21:56PM +0200, Jørgen Hovland wrote:
technology. Secondly, everybody should be able to keep their IP-address if they want (DNS is obviously not good enough). Not just PI-holders.
That's the *definition* of "PI" - "take it with you when you change your ISP". The whole point of having PA and PI is to make sure that as much aggregation is done as possible - and for many (smaller) companies, changing their IP addresses is much less effort than getting a new leased line. The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 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:
The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable.
This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured - pure pain. The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business. Nick
On Mon, 24 Apr 2006, Nick Hilliard wrote:
Gert Doering wrote:
The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable.
This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured - pure pain.
The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business.
So what you are saying are we need a better way to configure, reconfigure/change the connection to the end-users/customers? Thought IPv6 was suppose to solve that issue. -- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Roger - On Sun, 23 Apr 2006, Roger Jorgensen wrote:
On Mon, 24 Apr 2006, Nick Hilliard wrote:
Gert Doering wrote:
The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable.
This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured - pure pain.
The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business.
So what you are saying are we need a better way to configure, reconfigure/change the connection to the end-users/customers? Thought IPv6 was suppose to solve that issue.
IPv6 has made it possible to renumber the network almost automatically. it seems possible to make that change without a "flag day" and an outage. however, the tools are mostly *NOT* there for similarly easy renumbering of router ACLs and firewall configs and DNS, so as the size of the network increases, large organizations are saying there is still a significant cost to renumbering (at this time...). one can only hope that appropriate tools will be developed to make full renumbering reasonably painless. or the appropriate protocol enhancements are made so that local numbers become much less relevant to global routing? /Lea
On Sun, 23 Apr 2006, Lea Roberts wrote:
On Sun, 23 Apr 2006, Roger Jorgensen wrote:
On Mon, 24 Apr 2006, Nick Hilliard wrote:
The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable. This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured -
Gert Doering wrote: pure pain.
The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business. So what you are saying are we need a better way to configure, reconfigure/change the connection to the end-users/customers? Thought IPv6 was suppose to solve that issue. IPv6 has made it possible to renumber the network almost automatically. it seems possible to make that change without a "flag day" and an outage. however, the tools are mostly *NOT* there for similarly easy renumbering of router ACLs and firewall configs and DNS, so as the size of the network increases, large organizations are saying there is still a significant cost to renumbering (at this time...). one can only hope that appropriate tools will be developed to make full renumbering reasonably painless.
exactly! Let's use the time creatig the tools, create some standards and guidelines on HOWTO renumber instead of spending time reduing the same mistakes done in IPv4. We now have the change to save ourself from alot of trouble ~10-15years into the future...
or the appropriate protocol enhancements are made so that local numbers become much less relevant to global routing? /Lea
This would be an even better solution, but... it'll take time.... -- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
On Sun, 2006-04-23 at 18:54 +0200, Roger Jorgensen wrote: [mumbling about renumbering]
exactly! Let's use the time creatig the tools, create some standards and guidelines on HOWTO renumber instead of spending time reduing the same mistakes done in IPv4. We now have the change to save ourself from alot of trouble ~10-15years into the future...
Take a 200k+ node organisation, intra-dependencies with other companies and most of all external resources. Read: firewall rules at other parties, DNS servers hosted at other places and a lot lot more. There is no single tool which can cover that, that is a human issue as the other party will have to change things, if you can't reach them, you can't change. You don't want to wait for the other party to act. For many large organisations this will thus not work. Renumbering a large site is simply not easy. Indeed a small site (20 boxes max) with not too many external depencies can be done, but anything larger is a huge pain.
or the appropriate protocol enhancements are made so that local numbers become much less relevant to global routing? /Lea
This would be an even better solution, but... it'll take time....
This is why people are busy workin on SHIM6, HIP, SCTP and a number of other protocols. Still you will need a globally unique $something. IPv6 PI blocks can be used for this perfectly well. Just wait... before the routing tables explode (if they will) 16-bit ASN numbers run out any way and people will have to move to 32bit ASN's (funny isn't it that IPv4 is also 32bit, thus one will be addressing 32bits with 32bits...). The 32bit ASN's make sure that BGP won't go over the 2^32 routes, thus no problem there, as according to many the BGP tables can hold that (now lets see what convergence and flapping does ;) Greets, Jeroen
On Sun, Apr 23, 2006 at 06:54:58PM +0200, Roger Jorgensen wrote:
IPv6 has made it possible to renumber the network almost automatically. it seems possible to make that change without a "flag day" and an outage. however, the tools are mostly *NOT* there for similarly easy renumbering of router ACLs and firewall configs and DNS, so as the size of the network increases, large organizations are saying there is still a significant cost to renumbering (at this time...). one can only hope that appropriate tools will be developed to make full renumbering reasonably painless. exactly! Let's use the time creatig the tools, create some standards and guidelines on HOWTO renumber instead of spending time reduing the same mistakes done in IPv4. We now have the change to save ourself from alot of trouble ~10-15years into the future...
Your wording implies PI was a mistake in IPv4. I think it is one of the reasons for its success, not a mistake. Nils
On Sunday 23 April 2006 17:42, Lea Roberts wrote:
Roger -
On Sun, 23 Apr 2006, Roger Jorgensen wrote:
On Mon, 24 Apr 2006, Nick Hilliard wrote:
Gert Doering wrote:
The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable.
This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured - pure pain.
The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business.
So what you are saying are we need a better way to configure, reconfigure/change the connection to the end-users/customers? Thought IPv6 was suppose to solve that issue.
IPv6 has made it possible to renumber the network almost automatically. it seems possible to make that change without a "flag day" and an outage. however, the tools are mostly *NOT* there for similarly easy renumbering of router ACLs and firewall configs and DNS, so as the size of the network increases, large organizations are saying there is still a significant cost to renumbering (at this time...). one can only hope that appropriate tools will be developed to make full renumbering reasonably painless.
Did anyone try that in a mission crytical 200+ site network? That is what I'm looking at. I'm not conviced yet that one would really like to do that. Is anyone brave enough to calculate the risks and costs for a network like that? (We solved it via the LIR route by the way.) Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies.
On Mon, 2006-04-24 at 09:25 +0200, Marc van Selm wrote: On Sunday 23 April 2006 17:42, Lea Roberts wrote: [..]
IPv6 has made it possible to renumber the network almost automatically. it seems possible to make that change without a "flag day" and an outage. however, the tools are mostly *NOT* there for similarly easy renumbering of router ACLs and firewall configs and DNS, so as the size of the network increases, large organizations are saying there is still a significant cost to renumbering (at this time...). one can only hope that appropriate tools will be developed to make full renumbering reasonably painless.
Did anyone try that in a mission crytical 200+ site network? That is what I'm looking at. I'm not conviced yet that one would really like to do that. Is anyone brave enough to calculate the risks and costs for a network like that? (We solved it via the LIR route by the way.)
Unless you have a record of all the places where you have stored the sites IPv6 addresses and have (semi) direct access to change these, do not rely on having external parties update items on your list then it might be 'easily' done, for large varying values of 'easy'. If you do not meet any of the above then you will be in a large amount of pain in doing so. Especially the remote parties problem will cause a lot amount of pain as they need to do it in sync with you and they need to find out where all the changes have to be made. Even changing a 'home' setup can be hard when your DNS for instance is hosted at a remote site where you do not have direct access to. Renumbering is *NOT* simple and *CAN't* be automated (no remote company will allow you full automatic access to change things in their setup, think firewall rules for instance...) Greets, Jeroen
On Tue, Apr 25, 2006 at 01:24:15PM +0200, Jeroen Massar wrote:
If you do not meet any of the above then you will be in a large amount of pain in doing so. Especially the remote parties problem will cause a lot amount of pain as they need to do it in sync with you and they need to find out where all the changes have to be made.
There's an account of renumbering experiences here from work we did last year: http://www.6net.org/publications/deliverables/D3.6.1.pdf and http://www.6net.org/publications/deliverables/D3.6.2.pdf There's a lot of recommendations (20 or more) on things that would be useful to aid renumbering further. But the basic network oriented approach using prefix advertisements and deprecation works across the operating systems tested. As Jeroen says though, there's a wee bit more to it than that. Perhaps most importantly network management tools need updating to understand that IPv6 hosts may be multi-addressed, and to be able to validate/verify the phases of the renumbering process. -- Tim/::1
Renumbering is *NOT* simple and *CAN't* be automated (no remote company will allow you full automatic access to change things in their setup, think firewall rules for instance...)
Another example. My company laptop has a VPN client which has two IPv4 addresses in for the main and fallback VPN login servers. Even if there are systems in place for updating these settings when I reboot my laptop, that won't prevent helpdesk calls. For instance, it is common for people to put laptops to sleep without logging out. It may be a week or two between logins. If the network is renumbered, suddenly the VPN login service fails and remote users have to call a helpdesk to find out the new IP addresses. Processing a helpdesk call costs money and downtime due to lack of network access also costs money. It is difficult to foresee these kinds of costs. Now, if one or two companies does a renumber and runs into unforeseen costs and problems because of firewall configurations, VPN configurations, IP addresses stored in mobile phones, PDAs, inventory databases, smartcards, etc., then that will become publicised. Once other companies learn of these problems then they will refuse to renumber and will begin to demand fixed address assignments, i.e. PI addresses. The only way to convince these companies to renumber will be a protocol upgrade such as IPv4 to IPv6. I believe that the majority of companies will not be willing to accept renumbering after they have migrated to IPv6. The IPv6 migration will be THE LAST RENUMBERING!!! --Michael Dillon
Michael.Dillon@btradianz.com wrote: [ ... ]
Another example. My company laptop has a VPN client which has two IPv4 addresses in for the main and fallback VPN login servers.
Why does the laptop store the *addresses* instead of an (FQ)DN? Wilfried. PS: I can imagine a couple of different answers, but I'd like to get them "from the source"
Why does the laptop store the *addresses* instead of an (FQ)DN?
I have no idea. That is the way the IT department sets up things. But given that the VPN is a SECURITY measure, I suspect it has to do with the layers of security philosophy in which you implement many layers. According to this philosophy it is good to use a security layer even if it is not fully effective on its own. A real world example is locks on the doors of a building with glass windows. In this case, the IPv4 address is recorded to circumvent perceived weaknesses with DNS and to eliminate the possibility of man-in-the-middle attacks on the DNS. While some would argue that this is uneccessary since the VPN uses cryptographic security, others would point to SSH v1 vulnerabilities and the fact that RSA keys up to 450 bits have been cracked, to show that there is still a theoretical benefit to extra security layers. In any case, information security basically amounts to making it very complex for an attacker to manage all the contortions needed to break in within the time available to him. I wonder if the security community has put much thought into the kind of contortions which DNS elimination represents. After all, if DNS is used, then an attacker must subvert the DNS server or protocol. If it is not used then the attacker must subvert the IP routing system. Since we know that people are actively subverting routers and the routing system from time to time, I wonder whether the balance has shifted in favour of DNS. Of course, once DNS resolution has been applied, the routing system could still be subverted, but one could argue that round-robin dynamically updated A records could make it harder for the attacker to identify where the routing system needs to be compromised. Indeed, the blackhat community themselves are using this kind of dynamic DNS in order to evade whitehats attacking them. If there were a clearer analysis of these approachs rather than an outright rejection of things like DNS elimination, then I think we might be able to agree on best practices that meet both security needs and the need to keep networks in a maintainable (and renumberable) state. --Michael Dillon
On Tue, 25 Apr 2006 Michael.Dillon@btradianz.com wrote:
Renumbering is *NOT* simple and *CAN't* be automated (no remote company will allow you full automatic access to change things in their setup, think firewall rules for instance...) Another example. My company laptop has a VPN client which has two IPv4 addresses in for the main and fallback VPN login servers. Even if there are systems in place for updating these settings when I reboot my laptop, that won't prevent helpdesk calls. For instance, it is common for people to put laptops to sleep without logging out. It may be a week or two between logins. If the network is renumbered, suddenly the VPN login service fails and remote users have to call a helpdesk to find out the new IP addresses. Processing a helpdesk call costs money and downtime due to lack of network access also costs money. It is difficult to foresee these kinds of costs.
really bad example, you never have a 1 or 2 weeks periode (planned time) to renumber, you plan it over monthss to make sure things like you describe don't happen. Good planing avoid alot of issues.. and for the rest of your mail, why can't we all stop thinking in terms of IP addresses and start thinking in terms of hostnames? -- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
On Tue, Apr 25, 2006 at 07:41:19PM +0200, Roger Jorgensen wrote:
really bad example, you never have a 1 or 2 weeks periode (planned time) to renumber, you plan it over monthss to make sure things like you describe don't happen. Good planing avoid alot of issues..
Thats the point. You need to invest many man-months to renumber. That is what companies usually consider as being "expensive". Apart from the hassle with customers, telling them about your yearly renumbering and forcing them to do work again.
and for the rest of your mail, why can't we all stop thinking in terms of IP addresses and start thinking in terms of hostnames?
Because IP-Packets are using IP-Addresses and not hostnames to get to their destination. Nils -- This message will self-destruct after the default expiration-time.
Hi, On Mon, Apr 24, 2006 at 09:39:30AM +0100, Nick Hilliard wrote:
Gert Doering wrote:
The nice thing about Internet (as opposed to the telephone system) is the fact that we have DNS - and thus no need to take our "numbers" with us to be reachable.
This is certainly the theory. However, if you are a growing ISP, renumbering from PA space from another LIR to your own PI space or LIR/PA space can be - depending on how your customers are configured - pure pain.
Yes. Been there, done that. Couple of times (renumbering an ISP's recursive name servers is *very much* pain). But that's local pain. PI is global pain to everybody else.
The portability associated with PI space is also important in one other view, in that it allows the holder to switch providers quickly and efficiently. There's no tie-in of any form, and this is something which is extremely important to business.
This is the standard argument, but only half-true. For serious internet connections, you usually need to move your leased-line connection, or move your servers to a new colocation - which is, assuming ``standard'' setups and some planning in advance, comparable if not more effort to changing the addresses. A poorly planned network, with everything hardcoded everywhere (up to applications that access IP addresses hard-coded in the source) is not a proper excuse to burden everbody else's routers. I accept that PI for BGP multihoming purposes is - today - one of the more reasonable ways to achieve the goal (ISP independence and resilience), but I still hope that we won't ever see the "let's get PI once, and never have to renumber again!" land rush. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
This is the standard argument, but only half-true. For serious internet connections, you usually need to move your leased-line connection,
This can be solved by having physical IXes. This is not the same as existing logical IXes because in a physical IX, businesses will connect their circuits to the IX and then cross-connect to an ISP. There is no peering here, just cross-connect cables. To provide separacy, you need two or more physical IXes in a city. Such things do not exist today because it is not common for businesses to have PI space. This means that currently they are not able to switch providers quickly so there is no demand for a physical IX. Once geo-topo addressing is implemented, I expect that the peering exchanges will expand their business into offering this type of physical exchange service.
A poorly planned network, with everything hardcoded everywhere (up to applications that access IP addresses hard-coded in the source) is not a proper excuse to burden everbody else's routers.
Maybe that's why people who do hardcode addresses for security reasons, are building private internetworks. Of course, these people have the same right to PI addresses as everybody else. It doesn't matter whether you are on the public Internet or a private internet.
I accept that PI for BGP multihoming purposes is - today - one of the more reasonable ways to achieve the goal (ISP independence and resilience), but I still hope that we won't ever see the "let's get PI once, and never have to renumber again!" land rush.
You do realize that in IPv6 there is enough address space to supply such a "land rush" in an orderly manner so that everyone gets their unique PI block? --Michael Dillon
Hi, On Mon, Apr 24, 2006 at 10:07:58AM +0100, Michael.Dillon@btradianz.com wrote:
I accept that PI for BGP multihoming purposes is - today - one of the more reasonable ways to achieve the goal (ISP independence and resilience), but I still hope that we won't ever see the "let's get PI once, and never have to renumber again!" land rush.
You do realize that in IPv6 there is enough address space to supply such a "land rush" in an orderly manner so that everyone gets their unique PI block?
The problem is not the amount of address space. The problem is the pressure on the AS numbers, and the amount of slots in the global routing table. Which, as a matter of fact, won't be able to handle "an unique PI block for everyone" (5 billion?) any time soon. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
You do realize that in IPv6 there is enough address space to supply such a "land rush" in an orderly manner so that everyone gets their unique PI block?
The problem is not the amount of address space. The problem is the pressure on the AS numbers, and the amount of slots in the global routing table. Which, as a matter of fact, won't be able to handle "an unique PI block for everyone" (5 billion?) any time soon.
That is precisely why I am promoting the concept of geo-topo addressing. This solves global routing table problem by using roughly 5000 routes for city-based aggregates to serve millions of PI address blocks. And it can be done with no new protocols, no new technology and no changes to the existing PA address regime for ISPs which want to stick with pure classic PA addresses. Only ISPs which want to offer services to geo-topo address holders will need to make adjustments to their internal practices. --Michael Dillon
Hi, On Mon, Apr 24, 2006 at 12:24:32PM +0100, Michael.Dillon@btradianz.com wrote:
You do realize that in IPv6 there is enough address space to supply such a "land rush" in an orderly manner so that everyone gets their unique PI block? [..] That is precisely why I am promoting the concept of geo-topo addressing. This solves global routing table problem by using roughly 5000 routes for city-based aggregates to serve millions of PI address blocks. And it can be done with no new protocols, no new technology and no changes to the existing PA address regime for ISPs which want to stick with pure classic PA addresses. Only ISPs which want to offer services to geo-topo address holders will need to make adjustments to their internal practices.
Understood. I just wanted to comment on that specific comment, which wasn't made in the context of geo-topo addressing, but more "generally". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi,
I accept that PI for BGP multihoming purposes is - today - one of the more reasonable ways to achieve the goal (ISP independence and resilience), but I still hope that we won't ever see the "let's get PI once, and never have to renumber again!" land rush.
Please, take a look at hosting providers. Changing thousands of domains and sites (probably not under his control) is a Really Big Problem. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, On Mon, Apr 24, 2006 at 01:16:30PM +0400, Max Tulyev wrote:
I accept that PI for BGP multihoming purposes is - today - one of the more reasonable ways to achieve the goal (ISP independence and resilience), but I still hope that we won't ever see the "let's get PI once, and never have to renumber again!" land rush.
Please, take a look at hosting providers. Changing thousands of domains and sites (probably not under his control) is a Really Big Problem.
Most (if not all) larger hosting providers I know are LIRs, so this question really doesn't apply. And for smaller hosting providers, this can be done - yes, it's painful, but the alternatives are also painful. When asking for "PI-for-everbody" keep in mind that everybody *else* has to pay the cost, and if the pain level gets too high, might just decide to drop "PI-for-everbody" routes.. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi,
Most (if not all) larger hosting providers I know are LIRs, so this question really doesn't apply. And for smaller hosting providers, this can be done - yes, it's painful, but the alternatives are also painful.
In fact, no (especially, in .RU/.UA). But! Some of hosting providers are LIRs to have own IPs and AS, but many of them need no more than /24 (ok, /23 at the most), because of HTTP/1.1 nowdays is an industry standard. I also know many cases people get LIRs (and /20) because of they aware of potential (I think mostly imagined) PI problems, when they really need /24. What about conserving of address space? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
Hi, On Mon, Apr 24, 2006 at 02:56:59PM +0400, Max Tulyev wrote:
What about conserving of address space?
When talking about IPv6, and /32 or /48 allocations/assignments, routing table slots are more valuable than /48 blocks (because routers will explode long before the address space is done). IPv4 is legacy anyway, and the sooner it goes away, the better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Mon, 24 Apr 2006 13:07:03 +0200, "Gert Doering" <gert@space.net> said:
IPv4 is legacy anyway, and the sooner it goes away, the better.
Maybe in some ways, but there are many arguments in favor of making it last as long as possible too. This thread and similar threads on just about any ip-ops list show that far from everybody agree that there is a complete alternative to v4 yet. Remember, IPv6 and promises about scalable routing was once (mid 90s) one of the last nails in GOSIP's (and it's various national variations') coffin. Considering the development since, or lack thereof, it seems just fine if v4 can cope for a little while longer. //per -- Per Heldal http://heldal.eml.cc/
* Gert Doering:
Most (if not all) larger hosting providers I know are LIRs, so this question really doesn't apply.
Then we will arrive at "LIRs are global pain to everybody else", and nothing has changed.
Hi, On Sun, Apr 30, 2006 at 02:38:56PM +0200, Florian Weimer wrote:
Most (if not all) larger hosting providers I know are LIRs, so this question really doesn't apply. Then we will arrive at "LIRs are global pain to everybody else", and nothing has changed.
Which is touching the core of the problem: "can we agree upon who should be allowed to put a route into my routers"? LIRs seem to be a good choice, because many (most?) of them *do* allocate for third parties (which is a good thing for global aggregation) - and even for those that don't, the fact that there is a recurring fee involved shifts the balance a bit away from "PI is purely convenient for the holder and puts the costs only on everybody else" to "a portable IP block *does* have some costs attached". So in the end, we might want to abandon the "IPv6 PI" approaches, and radically change (loosen) the "IPv6 PA" policy. But *I* am not the one to decide that - I follow the discussions, and try to extract some sort of workable (for the next few years) compromise between the extreme positions, which will then re-enter the discussion. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Monday 01 May 2006 16:43, Gert Doering wrote:
a recurring fee involved shifts the balance a bit away from "PI is purely convenient for the holder and puts the costs only on everybody else" to "a portable IP block *does* have some costs attached".
Am I completely wrong here, or does a LIR pay for the privilege of assigning IP space to end-users? Which, looking at some "ISP"s insane business models ( €200/year for a /29 - hello?) could be a profitable business in itself. Having said that, there is no technical reason why PA and PI should be different at all - if anyone with routable IPv[46] space would be required to be a RIR member that should appease the "It's unfair that we should pay and have to deal with RIRs and others don't" faction. It would also give them access to the relevant training and tools. The LIR function would then be altogether separate from the IP space request function. I predict some opposition from the RIRs, though... rgds, s.
Hi, On Mon, May 01, 2006 at 06:25:19PM +0100, Sascha Luck wrote:
Am I completely wrong here, or does a LIR pay for the privilege of assigning IP space to end-users? Which, looking at some "ISP"s insane business models ( ???200/year for a /29 - hello?) could be a profitable business in itself.
The sum of the LIR fees pays for the RIPE NCC budget (which is non-profit, but is permitted to build some savings). The fees are explicitely not "per IP address" (so "two times the address space" doesn't mean "twice the fee") - *but* there is a address space dependent component, to better balance the fees between "small LIRs" and "large LIRs" - and there is no other easily applicable metric to measure a LIR's size than "internet resources used" (this model could be changed by the members in the RIPE AGM, btw). Even for large LIRs, the total yearly fee is not that much, compared to "having a few competent employees looking after their network". If some ISPs have funny business models, pick a different one. There are enough in the market place - but don't complain that your favourite "internet free for 2 EUR/month" ISP isn't offering everything that you'd like to see included in that 2 EUR...
Having said that, there is no technical reason why PA and PI should be different at all - if anyone with routable IPv[46] space would be required to be a RIR member that should appease the "It's unfair that we should pay and have to deal with RIRs and others don't" faction. It would also give them access to the relevant training and tools. The LIR function would then be altogether separate from the IP space request function.
Yes.
I predict some opposition from the RIRs, though...
I can't speak for other regions, but the RIPE NCC is there to serve the needs of the RIPE members - so if *we* decide that we want to change something, the RIPE NCC will implement it. And usually in a friendly and competent way. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 1 maj 2006, at 17.43, Gert Doering wrote:
Hi,
On Sun, Apr 30, 2006 at 02:38:56PM +0200, Florian Weimer wrote:
Most (if not all) larger hosting providers I know are LIRs, so this question really doesn't apply. Then we will arrive at "LIRs are global pain to everybody else", and nothing has changed.
Which is touching the core of the problem:
"can we agree upon who should be allowed to put a route into my routers"?
LIRs seem to be a good choice, because many (most?) of them *do* allocate for third parties (which is a good thing for global aggregation) - and even for those that don't, the fact that there is a recurring fee involved shifts the balance a bit away from "PI is purely convenient for the holder and puts the costs only on everybody else" to "a portable IP block *does* have some costs attached".
So in the end, we might want to abandon the "IPv6 PI" approaches, and radically change (loosen) the "IPv6 PA" policy.
But *I* am not the one to decide that - I follow the discussions, and try to extract some sort of workable (for the next few years) compromise between the extreme positions, which will then re-enter the discussion.
I actually agree with Gert. If we for a moment ignores who has the right to a slot in the routing table, I think the entire notion of PI should be abandoned as we have it today. I want holders of address space to have a recurring contact with the RIRs to make sure contact data is accurate and the holder still exists. I further think that all address-space holders should be subject to the same rules. Now, changing the rules for what is already out there does not seem doable, but at least we should change for the future. If PA space policy is broken, let's fix that. As for who have a right to a slot in my routing table, I think a minimum requirement is that they can be bothered to fulfil the duties as an LIR. If they can't be bothered with that, I can't be bothered to carry their route. So, let's move to a discussion on who should be able to get PA space.... I think being an LIR is a minimum requirement, that includes paying the associated fees. The 200 rule is questionable to me, it's arbitrary and more or less impossible to enforce. The demand that the space actually be used on the public routable Internet seems good if we could define this clearly. Leo told me that the NCC receives approx ~1400 requests a year for IPv4 PI space. I wonder how much of that is going to ISPs becuase it's "cheaper" than PA space...which is a claim that is hard to quantify. Well, this might be enough to start a discussion... - kurtis -
On Mon, 2006-05-01 at 20:12 +0200, Kurt Erik Lindqvist wrote:
On 1 maj 2006, at 17.43, Gert Doering wrote: [..] I actually agree with Gert. If we for a moment ignores who has the right to a slot in the routing table, I think the entire notion of PI should be abandoned as we have it today. I want holders of address space to have a recurring contact with the RIRs to make sure contact data is accurate and the holder still exists. I further think that all address-space holders should be subject to the same rules. Now, changing the rules for what is already out there does not seem doable, but at least we should change for the future. If PA space policy is broken, let's fix that.
PA is what it says: Provider Address space, thus address space for end-users provided by their provider. These get >/32+ PI is provider independent, and thus for endsites, typically /48's, maybe upto a /44 or so. I would keep them seperate names because of this. Though one could also merge them. The thing is that they will, at some point, pop up both in the routing tables, assuming no other solution arrives, and they are both based on the amount of address space usage. Having the seperate might later on easily allow them to be seperated.
As for who have a right to a slot in my routing table, I think a minimum requirement is that they can be bothered to fulfil the duties as an LIR. If they can't be bothered with that, I can't be bothered to carry their route. So, let's move to a discussion on who should be able to get PA space....
Being LIR makes at least sure that somebody (or a consultant) at the organisation has some RIR clue and most likely also some routing clue. This is already a reasonable financial and work-load barrier. The people who decide on that one gets an entry in the routing table are the folks who accept the route. Not the community. Though one could set a sort of default community policy or so. The IPv4 /24-/32 filtering is not a carved in stone standard either but most ISP's are doing it anyway.
I think being an LIR is a minimum requirement, that includes paying the associated fees.
Ack. And if you can't pay the fees or pay a LIR then you most likely can't pay for proper hardware and maintainance either ;)
The 200 rule is questionable to me, it's arbitrary and more or less impossible to enforce.
The PA 200 is currently more a stopper for very small sites of getting PA space in a /32 chunk which they will never use.
The demand that the space actually be used on the public routable Internet seems good if we could define this clearly.
That would be COMPLETELY silly. It's address space, no routability is guaranteed and then you require it to be routed onto the internet? What do you want, people to announce their space and then blackhole it? ISP's request address space, for what they use it is their right. As long as they actually use the space they requested of course.
Leo told me that the NCC receives approx ~1400 requests a year for IPv4 PI space. I wonder how much of that is going to ISPs becuase it's "cheaper" than PA space...which is a claim that is hard to quantify.
PI is for folks wanting to be independent. Independency is most of the time a bit more expensive. Thus IMHO in very short: - PA policy is for Providers, these provide access to endsites. - PI policy is for Endsites. Pricing should be LIR-fee + annual renenewal depending on the size of the space received. That said RIR's don't say who gets a slot in the routing space and policy should not forbid people getting address space, if it is meant for the internet or for other use. As long as an entity can show the demand for the amount of requested address space and is willing to pay the price they should be able to get it. The routability factor they can guarantee by being cool enough and persuading other ISP's to accept their announcements. Currently (peeing at GRH) that means if you have a /48 it will simply work(tm). This might change over the coming years though, solutions will come... also see my longer message about address space & routing slots on ppml@arin... My couple of rappen... Greets, Jeroen
On 2 maj 2006, at 11.47, Jeroen Massar wrote:
On Mon, 2006-05-01 at 20:12 +0200, Kurt Erik Lindqvist wrote:
On 1 maj 2006, at 17.43, Gert Doering wrote: [..] I actually agree with Gert. If we for a moment ignores who has the right to a slot in the routing table, I think the entire notion of PI should be abandoned as we have it today. I want holders of address space to have a recurring contact with the RIRs to make sure contact data is accurate and the holder still exists. I further think that all address-space holders should be subject to the same rules. Now, changing the rules for what is already out there does not seem doable, but at least we should change for the future. If PA space policy is broken, let's fix that.
PA is what it says: Provider Address space, thus address space for end-users provided by their provider. These get >/32+
PI is provider independent, and thus for endsites, typically /48's, maybe upto a /44 or so.
It's more than that. PA comes with an annual cost and contact with the RIPE NCC. PI is free more or less for life with no guaranteed record keeping or guarnatee that the owner even exists. See experiences from ERX.
I would keep them seperate names because of this. Though one could also merge them. The thing is that they will, at some point, pop up both in the routing tables, assuming no other solution arrives, and they are both based on the amount of address space usage. Having the seperate might later on easily allow them to be seperated.
I am less concerned about what you end up calling it than I am with 1) Keeping track of it 2) Having the owners follow the same policy
As for who have a right to a slot in my routing table, I think a minimum requirement is that they can be bothered to fulfil the duties as an LIR. If they can't be bothered with that, I can't be bothered to carry their route. So, let's move to a discussion on who should be able to get PA space....
Being LIR makes at least sure that somebody (or a consultant) at the organisation has some RIR clue and most likely also some routing clue. This is already a reasonable financial and work-load barrier.
Yes, that is the point.
The 200 rule is questionable to me, it's arbitrary and more or less impossible to enforce.
The PA 200 is currently more a stopper for very small sites of getting PA space in a /32 chunk which they will never use.
Whatever it is, it's arbitrary and comes with it's own set of problems.
The demand that the space actually be used on the public routable Internet seems good if we could define this clearly.
That would be COMPLETELY silly. It's address space, no routability is guaranteed and then you require it to be routed onto the internet? What do you want, people to announce their space and then blackhole it? ISP's request address space, for what they use it is their right. As long as they actually use the space they requested of course.
It's not that long ago this was the requirement for IPv4 space...
Leo told me that the NCC receives approx ~1400 requests a year for IPv4 PI space. I wonder how much of that is going to ISPs becuase it's "cheaper" than PA space...which is a claim that is hard to quantify.
PI is for folks wanting to be independent. Independency is most of the time a bit more expensive.
PI space is free for life.
Thus IMHO in very short: - PA policy is for Providers, these provide access to endsites. - PI policy is for Endsites.
Look, it's the same routing table slot, and it's the same addresses. Just that one is yours to keep forever, free of charge, and no requirement to keep uptodate records. PI as we know it should go. Or be subject to the same conditions as PA space. I wouldn't be surprise to find ISPs using PI space....
Pricing should be LIR-fee + annual renenewal depending on the size of the space received.
Yupp. - kurtis -
Hi, On Tue, May 02, 2006 at 10:08:02PM +0200, Kurt Erik Lindqvist wrote:
I wouldn't be surprise to find ISPs using PI space....
Which happened quite frequently during the time where we had the idea to conserve IPv4 addresses by requiring a minimum utilization before a new LIR could get an initial PA block. Which ended up hurting routing, and not conserving very many addresses. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Just a technical/financial clarification.... Kurt Erik Lindqvist wrote: [ ... ]
PI is for folks wanting to be independent. Independency is most of the time a bit more expensive.
PI space is free for life.
Not really. Quite a while ago the NCC stopped accepting PI requests from "walk-in" applicants (as we told them to do). Since then an application for PI (and ASNs) can only be submitted by way of an LIR. And those assignments do count against their "size" calculation: http://www.ripe.net/ripe/docs/charging.html The table with the scoring units and the formula for category determination can be found close to the end of that page.
Thus IMHO in very short: - PA policy is for Providers, these provide access to endsites. - PI policy is for Endsites.
[ ... ]
- kurtis -
Wilfried.
Wilfried Woeber, UniVie/ACOnet schrieb: Hi,
PI is for folks wanting to be independent. Independency is most of the time a bit more expensive. PI space is free for life. Not really.
Quite a while ago the NCC stopped accepting PI requests from "walk-in" applicants (as we told them to do).
Since then an application for PI (and ASNs) can only be submitted by way of an LIR. And those assignments do count against their "size" calculation:
Yes, but only in the first year (no way else to do it, the LIR will not have a customer/billing-relationship with the PI "owner" forever). And at least a few LIRs don't even charge their customer in the first year if they don't get pushed in the next billing category due to PI requests. I know of a few ISPs that chose PI space over PA space (for example with a subsidiary company as applicant) because it is cheaper in the long term. The RIRs either need to have a direct billing relationship with PI holders or PI has to be transferable between LIRs (on whose bill it is with a fixed amout, this billing point scheme is imho not suitable for this), otherwise a recurring fee is not possible. Regards, Bernhard
On Monday 01 May 2006 20:12, Kurt Erik Lindqvist wrote:
On 1 maj 2006, at 17.43, Gert Doering wrote:
[...]
I actually agree with Gert. If we for a moment ignores who has the right to a slot in the routing table, I think the entire notion of PI should be abandoned as we have it today. I want holders of address space to have a recurring contact with the RIRs to make sure contact data is accurate and the holder still exists.
Good point. Why don't we approach it from that way then. We have a holder of an IP block. A LIR hands them out on behalf of others and is also an aggregation point. An org. that needs a block of its own (ignoring the criteria for a moment) has the same aggregation responsibility. They also have a payment responsibility towards the RIR (or a LIR (why not have a mediator role for the LIR with handing out a PI block if they like that business model)). So LIR or organization: same responsibilities and payment scheme. Getting IP space from a LIR generally means getting connectivity also. If you get PI space, you get no connectivity but you get that elsewhere. So same rules for routing and payment but the difference is address block + connectivity and address block - connectivity. Then a PI policy is more or less a copy of the LIR policy without the posibility/requirement to allocate on behalf of others. I guess the PI "owner's" transmission provider or peering partner will keep him sane with respect to doing the right routing thing. Does this approach make sense? [...]
Well, this might be enough to start a discussion...
- kurtis -
-- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
Hi, Kurt Erik Lindqvist wrote: [...]
this clearly. Leo told me that the NCC receives approx ~1400 requests a year for IPv4 PI space. I wonder how much of that is going to ISPs becuase it's "cheaper" than PA space...which is a claim that is hard to quantify.
You can see some historical information about PI assignments (and other information) in slides 5, 6 and 7 of the RIPE NCC Numbers Update I presented last week: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-ripe_... We also have numbers showing the numbers of PI assignments per prefix length last year. These numbers include a few assignments made to trade fairs, conferences and so on. /18 1 /19 5 /20 24 /21 54 /22 268 /23 400 /24 730 /25 10 /26 9 /27 5 /29 2 I hope these data are useful. Regards, -- leo vegoda Registration Services Manager RIPE NCC
* Gert Doering:
Which is touching the core of the problem:
"can we agree upon who should be allowed to put a route into my routers"?
Ideally, that would be someone who pays for this kind of service. The fewer prefixes there are, the more feasible this approach will be. 8-)
LIRs seem to be a good choice, because many (most?) of them *do* allocate for third parties (which is a good thing for global aggregation) - and even for those that don't, the fact that there is a recurring fee involved shifts the balance a bit away from "PI is purely convenient for the holder and puts the costs only on everybody else" to "a portable IP block *does* have some costs attached".
In principle, such an effect is desirable. But I would be very surprised if the majority of end users with IPv4 PI didn't pay a monthly fee for non-mass-market Internet connectivity. This means that they actually need PI, or they don't care that much because the price difference still isn't large enough. In the latter case, a rather significant fee is needed to turn global inconvenience into a local one.
On Monday 08 May 2006 06:28, Florian Weimer wrote:
In the latter case, a rather significant fee is needed to turn global inconvenience into a local one.
An arbitrary fee, specifically designed to block someone's entry into *any* market, is *illegal*, at least in any non-communist country that I know. I also don't understand the whole decision circling back, endlessly, to restrictive policies when nobody actually seems to want IPv6 (assuming this is still what we're talking about) rgds, s.
At 19:01 08/05/2006, Sascha Luck wrote:
On Monday 08 May 2006 06:28, Florian Weimer wrote:
In the latter case, a rather significant fee is needed to turn global inconvenience into a local one.
An arbitrary fee, specifically designed to block someone's entry into *any* market, is *illegal*, at least in any non-communist country that I know.
I also don't understand the whole decision circling back, endlessly, to restrictive policies when nobody actually seems to want IPv6 (assuming this is still what we're talking about)
At the moment I would like to get an IPv6 block for one of the transit networks we manage. They are being prevented from trying IPv6 because I can't get a PI block for it and it doesn't, as such, have any customers to which it allocates space. I want PI space for it because the intention is for this network to be "spun off" and become self-managing. And, I see no reason that management of this network might not be out-sourced to some distant country, so I want this block to be routed, please. Folks are going to come to terms with the fact that the v6 routing table is going to have large numbers of entries. Attempts to prevent this can only be done with restrictive policies, as you say. If we *don't* want the v6 routing table to have more than a few entries, we better adopt strictly geographical addressing (like the phone system) and hand the whole thing over to the ITU. -- Tim
On Tue, 2006-05-09 at 10:03 +0100, Tim Streater wrote:
At 19:01 08/05/2006, Sascha Luck wrote:
An arbitrary fee, specifically designed to block someone's entry into *any* market, is *illegal*, at least in any non-communist country that I know.
[...] Folks are going to come to terms with the fact that the v6 routing table is going to have large numbers of entries.
IPv6 will be much better aggregated than ipv4, because the allocation blocks are larger, and the requirement for LIRs to request multiple non-contiguous blocks of space will be much lower. This necessarily means that ipv6 table growth is going to be lesser than the ipv4 table growth, which has also lagged behind hardware speed increases. What's the problem here?? As regards cost, PI space requires RIR administration, and that costs money. Additionally, there needs to be a means for RIRs to legitimately reclaim PI space. Charging a fee appears to be good way of dealing with both problems. It doesn't need to be a huge amount of money, but money needs to be involved. I would like to suggest that after initial liaison with the local LIR, that the end-user relationship would then revert to the RIR. The RIR would then be responsible for charging the end-user, and the LIR would be removed from the equation. This will require time and resources to set up, and that means that charging a fee will be completely justified. This will fix two things which completely fail to make sense about the current RIPE (ipv4) assignment policy: 1. there is no default means of returning PI space to the RIR if the end-user disappears 2. the LIR is effectively charged for the assignment, even if the end-user moves to another LIR's domain. Problem #1 is a really serious issue and needs to be tackled urgently. Nick
At 10:44 09/05/2006, Nick Hilliard wrote:
On Tue, 2006-05-09 at 10:03 +0100, Tim Streater wrote:
At 19:01 08/05/2006, Sascha Luck wrote:
An arbitrary fee, specifically designed to block someone's entry into *any* market, is *illegal*, at least in any non-communist country that I know.
[...] Folks are going to come to terms with the fact that the v6 routing table is going to have large numbers of entries.
IPv6 will be much better aggregated than ipv4, because the allocation blocks are larger, and the requirement for LIRs to request multiple non-contiguous blocks of space will be much lower. This necessarily means that ipv6 table growth is going to be lesser than the ipv4 table growth, which has also lagged behind hardware speed increases. What's the problem here??
The fact that there are many more bits to allocate.
As regards cost, PI space requires RIR administration, and that costs money. Additionally, there needs to be a means for RIRs to legitimately reclaim PI space. Charging a fee appears to be good way of dealing with both problems. It doesn't need to be a huge amount of money, but money needs to be involved.
I would like to suggest that after initial liaison with the local LIR, that the end-user relationship would then revert to the RIR. The RIR would then be responsible for charging the end-user, and the LIR would be removed from the equation.
This will require time and resources to set up, and that means that charging a fee will be completely justified. This will fix two things which completely fail to make sense about the current RIPE (ipv4) assignment policy:
1. there is no default means of returning PI space to the RIR if the end-user disappears 2. the LIR is effectively charged for the assignment, even if the end-user moves to another LIR's domain.
Problem #1 is a really serious issue and needs to be tackled urgently.
I think these are very good suggestions; there should be an annual fee for use of the PI block. This will fix the administrative aspects and should be retro-fitted to v4. Moving to the RIR administering the PI space also protects against the LIR disappearing. -- Tim
On Tue, 2006-05-09 at 10:55 +0100, Tim Streater wrote:
The fact that there are many more bits to allocate.
The actual number of bits is largely irrelevant to what we're talking about here. The real determinant of the problem is the number of discrete allocations and assignments announced, and this will be a function of the number of discrete networks required to service the globe. This will increase as connectivity increases, but it will ultimately plateau at some stage, or at least it will reach a stage where growth (i.e. rate of increase) will drop significantly. And as I said already, because of the allocation policies in place, ipv6 table growth will always trail the equivalent network prefix requirement for ipv4. Nick
On Tuesday 09 May 2006 10:44, Nick Hilliard wrote:
As regards cost, PI space requires RIR administration, and that costs money. Additionally, there needs to be a means for RIRs to legitimately reclaim PI space. Charging a fee appears to be good way of dealing with both problems. It doesn't need to be a huge amount of money, but money needs to be involved.
Don't get me wrong, I've already said I agree fully with the need for PI-holders to become RIR-members (with associated cost). It's a fee, set arbitrarily high specifically to deter PI as suggested in the post I was responding to, that I have a problem with. rgds, s.
On Tuesday 09 May 2006 10:44, Nick Hilliard wrote:
As regards cost, PI space requires RIR administration, and that costs money. Additionally, there needs to be a means for RIRs to legitimately reclaim PI space. Charging a fee appears to be good way of dealing with both problems. It doesn't need to be a huge amount of money, but money needs to be involved.
Don't get me wrong, I've already said I agree fully with the need for PI-holders to become RIR-members (with associated cost). It's a fee, set arbitrarily high specifically to deter PI as suggested in the post I was responding to, that I have a problem with. rgds, s. -- DDO Eirconnect
Nick Hilliard wrote:
Folks are going to come to terms with the fact that the v6 routing table is going to have large numbers of entries.
IPv6 will be much better aggregated than ipv4, because the allocation blocks are larger, and the requirement for LIRs to request multiple non-contiguous blocks of space will be much lower.
It merely means difference of a small constant factor.
This necessarily means that ipv6 table growth is going to be lesser than the ipv4 table growth, which has also lagged behind hardware speed increases. What's the problem here??
IPv4 routing table is already too large that its convergence is prohibitively slow. Moreover, as hardware becomes more and more optical, large routing table becomes slower and slower to lookup.
1. there is no default means of returning PI space to the RIR if the end-user disappears
Problem #1 is a really serious issue and needs to be tackled urgently.
Not at all. If the end-user disappears, its entries in global routing tables are tackled automatically. Masataka Ohta
On Tue, 2006-05-09 at 20:16 +0900, Masataka Ohta wrote:
Nick Hilliard wrote:
IPv6 will be much better aggregated than ipv4, because the allocation blocks are larger, and the requirement for LIRs to request multiple non-contiguous blocks of space will be much lower.
It merely means difference of a small constant factor.
I disagree. Most ISPs I know of announce a large number of non- contiguous address blocks. With ipv6, this will drop to just one or two in the short term; longer term, it will grow, but not even nearly at the same rate as ipv4 allocations.
IPv4 routing table is already too large that its convergence is prohibitively slow.
Geoff Huston's talk about this at RIPE was rather interesting. Yes, the routing table will grow. But that's only part of the problem; a bigger part of the problem is routing churn. Take a look at pages 37 and 38 of: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-bgp-r... You can see that there is a small number of organisations responsible for massive numbers of updates. I can tell you that If I were supreme ruler of the universe, these organisations would get a smack on the face.
Not at all. If the end-user disappears, its entries in global routing tables are tackled automatically.
The prefix announcement disappears, but the space is lost to the available address pool forever (under current rules). Nick
Nick Hilliard wrote:
It merely means difference of a small constant factor.
I disagree. Most ISPs I know of announce a large number of non- contiguous address blocks. With ipv6, this will drop to just one or two in the short term; longer term, it will grow, but not even nearly at the same rate as ipv4 allocations.
According to your favourite:
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-bgp-r...
each ISP announces, in average, about 8 blocks, which is the small constant factor.
IPv4 routing table is already too large that its convergence is prohibitively slow.
Geoff Huston's talk about this at RIPE was rather interesting. Yes, the routing table will grow. But that's only part of the problem;
So, you have found the problem. That's enough to answer the quesiton in your previous mail of: What's the problem here??
Not at all. If the end-user disappears, its entries in global routing tables are tackled automatically.
The prefix announcement disappears, but the space is lost to the available address pool forever (under current rules).
It's not a serious issue for IPv6 and no urgent response necessary, though you said in your previous mail Problem #1 is a really serious issue and needs to be tackled urgently. Masataka Ohta
each ISP announces, in average, about 8 blocks, which is the small constant factor.
Yes, but in an ipv6 world, i don't really see why the average would be much more than 2 or 3. Most AS's will announce just one.
Geoff Huston's talk about this at RIPE was rather interesting. Yes, the routing table will grow. But that's only part of the problem;
So, you have found the problem.
We all know that the two problems are routing table size and churn. But the two are not particularly related. A large routing table does not necessarily mean extra churn. Nick
On May 9, 2006, at 8:22 AM, Nick Hilliard wrote:
Yes, but in an ipv6 world, i don't really see why the average would be much more than 2 or 3. Most AS's will announce just one.
How do you believe folks will do traffic engineering? Rgds, -drc
David Conrad wrote:
How do you believe folks will do traffic engineering?
This is an interesting point which occurred to me as I was writing my last email. Outside as-path prepending, I don't have a good answer. Where the relevant organisations have multiple connections to the same upstream, it can be managed using no-export subnet announcements alongside the main supernet announcement. But where there are multiple upstreams involved this will, of course, not work. AS path prepending will continue work to the extent that it does today, which is to say not very well. But the point remains. The default LIR allocation size is /32, which allows for 65K /48's. That is a large number of distinct networks, and will easily satisfy the long-term requirements of small to medium sized ISPs, which - I am going to speculate - comprise the bulk of both AS's and prefix announcements. And if the recommended assignment size were to be changed from /48 to /56 - again allowing ample block size for many organisations, that would optimise address space utilisation further, making a /32 allocation last much longer than previously. Nick
At 05:28 AM 11/05/2006, Nick Hilliard wrote:
David Conrad wrote:
How do you believe folks will do traffic engineering?
This is an interesting point which occurred to me as I was writing my last email. Outside as-path prepending, I don't have a good answer.
And of course there are more specifics to play with as well, as well as AS sets and AS Path poisioning, as well as BGP communities of course. Playing with the routing system to attempt to achieve local optimizations at the expense of the global system is a well understood conventional path here. Geoff
* Nick Hilliard:
Geoff Huston's talk about this at RIPE was rather interesting. Yes, the routing table will grow. But that's only part of the problem; a bigger part of the problem is routing churn.
Take a look at pages 37 and 38 of:
http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-bgp-r...
Interesting. But -- obviously, it's not a significant problem. Otherwise, there would be peer pressure to fix it. Unlike things like BCP38, it's clear where the unnecessary BGP announcements/withdrawals come from.
You can see that there is a small number of organisations responsible for massive numbers of updates. I can tell you that If I were supreme ruler of the universe, these organisations would get a smack on the face.
The number of origin ASNs may be small, but their uplinks and peering partners support this behavior, at least passively.
* Sascha Luck:
On Monday 08 May 2006 06:28, Florian Weimer wrote:
In the latter case, a rather significant fee is needed to turn global inconvenience into a local one.
An arbitrary fee, specifically designed to block someone's entry into *any* market, is *illegal*, at least in any non-communist country that I know.
Have a look at frequency auctions and how they are used to lock out competition from small players. Many drastic measures are completely legal.
I also don't understand the whole decision circling back, endlessly, to restrictive policies when nobody actually seems to want IPv6 (assuming this is still what we're talking about)
The majority of those who post on the RIPE mailing lists deeply fear that there is a real demand for IPv6, so much that their routers are overloaded. I don't know why.
Florian Weimer wrote:
I also don't understand the whole decision circling back, endlessly, to restrictive policies when nobody actually seems to want IPv6 (assuming this is still what we're talking about)
The majority of those who post on the RIPE mailing lists deeply fear that there is a real demand for IPv6, so much that their routers are overloaded. I don't know why.
My understanding is that the IPv4 Internet failed to limit the size of DFZ that BGP convergence is taking prphibitively long time for mission critical applications. Moreover, considering bandwidth requirement for the next 5 or 10 years, I don't think backbone routers can have huge routing tables. Masataka Ohta
Hi, On Wed, May 10, 2006 at 09:26:04AM +0900, Masataka Ohta wrote:
Moreover, considering bandwidth requirement for the next 5 or 10 years, I don't think backbone routers can have huge routing tables.
Looking at the architecture of modern routing gear I fail to understand how "forwarding plane speed" relates to "control plane convergence time". That is: whether the forwarding plane has 1 Gbit/s or 1 Tbit/s has no influence on the convergence time, if the control plane is the same. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 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:
Hi,
Hi,
Moreover, considering bandwidth requirement for the next 5 or 10 years, I don't think backbone routers can have huge routing tables.
Looking at the architecture of modern routing gear I fail to understand how "forwarding plane speed" relates to "control plane convergence time".
I'm not saying such a thing. I'm saying that, given a so short duration for routing table lookup, we must make memory for routing table smaller and simpler. Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns. If you try to solve the problem by parallelizm, you must provide tens or hundreds copies of routing table hardware, which consumes a lot of money and power. That is, there are at least two reasons, one is convergence time and the other is look up time, to make backbone routing table small. Masataka Ohta
On Wed, 10 May 2006 16:59:31 +0900, Masataka Ohta wrote:
I'm saying that, given a so short duration for routing table lookup, we must make memory for routing table smaller and simpler. Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns.
Have you ever heared of multi stage lookup using _pipelining_ ? If not, please don't spread FUD. If yes, you should be able to understand why your problem isn't a problem at all. 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
Oliver Bartels wrote:
I'm saying that, given a so short duration for routing table lookup, we must make memory for routing table smaller and simpler. Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns.
Have you ever heared of multi stage lookup using _pipelining_ ?
Yes, of course. Sometimes, pipelining can improve performance by a small constant factor with a small amount of additional hardware.
If yes, you should be able to understand why your problem isn't a problem at all.
Pipelining requires pipeline resigters. If you have too much stages of pipelining, additional amount of pipeline registers kills the benefit. Masataka Ohta
On Wed, 10 May 2006 17:53:36 +0900, Masataka Ohta wrote:
Sometimes, pipelining can improve performance by a small constant factor with a small amount of additional hardware.
Sorry: *LOL* With this statement ("small constant factor") you have just proven that you are far away with your routing table lookup theory from any real design. With today's CPU's we are talking of about 20 pipeline stages ... The advances in processing speed in the last ten years are - to a significant degree - based on advanced in multi- level and parallel pipelined CPU architectures (called superscalar processors).
Pipelining requires pipeline resigters.
If you have too much stages of pipelining, additional amount of pipeline registers kills the benefit.
Sorry, but it seems to me that you are talking about developments you have never been involved in. Pipeline registers are D-Flipflops, build as Master Slave static or e.g. using transfer gates, they are the _basic_ elements of any real IC design. These elements determinate - together with the conditional logic between them - the maximum permitted clock frequency. RAM is never ever faster than a single D-Flipflop using the same technology. Pipeline _stalls_ are a problem with CPU's, if we talk about an conditional instruction and if the branch prediction fails. With IP routing with multistage lookup there simply aren't such conditional instructions. IP routing fits ideal with pipelining, as there is no dependence between different IP packets, the first section of the pipeline decodes the first portion of the IP address, then passes the packet header to the next section responsible for the next portion of the address, at this time the first section starts decoding the next packet etc. If a delay is required, e.g. opening a new RAM page based on the first decode, then the packet header is put in the loop for one cycle. This is the difference between _throughput_ and _latency_ required by a forwarding engine. Thus if constructed the right way, handling reasonably large tables should not be a problem at all. 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
Oliver Bartels wrote:
IP routing fits ideal with pipelining, as there is no dependence between different IP packets, the first section of the pipeline decodes the first portion of the IP address, then passes the packet header to the next section responsible for the next portion of the address, at this time the first section starts decoding the next packet etc.
It merely means that pipeline clock can be as short as memory clock regardless of the number of memory references. However, as I said
Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns.
and as there are a lot of shorter packets, we should be able to lookup routing tables for, say, every 1ns or 0.1ns. If we have a 1Tbps port and a pipelined memory with pipeline clock of 200MHz, we need 5 copies of routing tables lnterleaved 5 ways for the port. If we have a router with 10 1Tbps ports, we need 50 copies for the router. So, it's better to have 50 copies of small memory than large memory. Or, can you make already pipelined memory operating at 200MHz 5 or 50 times more faster by 5 or 50 times more stages of pipeline? Note that, if you assume GaAs and/or full custom chips for further performance, please don't forget costs associated for it considering the number of backbone routers. Note also that, if you want to put everything on a chip to increase clock, there is a very hard limit on the routing table size. Masataka Ohta
On Wed, 10 May 2006 20:58:19 +0900, Masataka Ohta wrote:
Note that, at 1Tbps, 500B packet is 4ns long, at 10Tbps 0.4ns.
If we are able to provide 1Tbps at a single port in a single data stream, then for sure we will have the memory. Otherwise we won't have packet buffers and thus the whole discussion is senseless. Today we use DWDM, as we neither have 1 THz optics nor packet buffers ... Until then this here:
Or, can you make already pipelined memory operating at 200MHz 5 or 50 times more faster by 5 or 50 times more stages of pipeline?
http://www.idt.com/products/files/10154/FLYR-NSE-00104.pdf http://www.idt.com/products/files/9838/18MbDDRB4.pdf solves your "problem" which isn't one. Add a piece of DDRAM or RDRAM and make your table as large as you like. Spend anyone on this world a PI, it still will work if build properly ... Technology is not the PI/PA<200 problem. The problem is just a "I DO NOT WANT THIS", "I BELIEVE", "I DON'T LIKE" by certain people. In my personal view the main reason for this is a "loss of face" conflict by those who claim we can't build routers which handle large tables. 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
Oliver Bartels wrote:
If we are able to provide 1Tbps at a single port in a single data stream, then for sure we will have the memory.
Of course. And, it's doable even with packet buffers with realistic size and packet loss possibility. Otherwise, parallel datapath requires so much money and power that those for routing table is negligible from the beginning.
Today we use DWDM,
That's fine. The point is to switch all the wave lengths at once, just like EDFAs amplify all the wave lengths at once.
Or, can you make already pipelined memory operating at 200MHz 5 or 50 times more faster by 5 or 50 times more stages of pipeline?
http://www.idt.com/products/files/10154/FLYR-NSE-00104.pdf http://www.idt.com/products/files/9838/18MbDDRB4.pdf
solves your "problem" which isn't one.
It's merely 1.25 times faster than my example that it is no solution.
The problem is just a "I DO NOT WANT THIS", "I BELIEVE", "I DON'T LIKE" by certain people.
The problem is merely that you don't know the capability of combined photonic/electric circuit. Masataka Ohta
[cc: line trimmed]
The problem is just a "I DO NOT WANT THIS", "I BELIEVE", "I DON'T LIKE" by certain people.
This opinion was based on the memory of a time when routing table size threatened to exceed the maximum capacity of the routers of the day, and would have exceeded this capacity without the introduction of CIDR and strong aggregation. Once bitten, twice shy. So we are left with a legacy that strong aggregation is good policy, and our addressing allocation requirements are substantially based on this policy. We don't have such a problem with routing table size these days, but the engineering point was made and is still valid. Nick
Hi, Masataka Ohta wrote:
Florian Weimer wrote:
I also don't understand the whole decision circling back, endlessly, to restrictive policies when nobody actually seems to want IPv6 (assuming this is still what we're talking about)
The majority of those who post on the RIPE mailing lists deeply fear that there is a real demand for IPv6, so much that their routers are overloaded. I don't know why.
My understanding is that the IPv4 Internet failed to limit the size of DFZ that BGP convergence is taking prphibitively long time for mission critical applications.
Based on what? Please elaborate. (I run Corporate Networks with routing table sizes >> Internet DFZ due to /32 announcements and such stuff, no BGP Problems on good setups.)
Moreover, considering bandwidth requirement for the next 5 or 10 years, I don't think backbone routers can have huge routing tables.
I think i don't need to add anything here, other's already replied to that. It's - sorry - nonsense. But yes, of course, the smaller the table, the better. There is just no agreement on how to achieve a "small table". I say (like others), there is no problem at all, IPv6 Addressing Scheme and additional Multihoming solutions solve all problems on their own. One should rather care for the IPv4 table, it will continue to grow for a decade or so. THAT is the problem which fills your TCAM memories, not the growing IPv6 table. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
Sascha Lenz wrote: Hi,
My understanding is that the IPv4 Internet failed to limit the size of DFZ that BGP convergence is taking prphibitively long time for mission critical applications.
Based on what?
I think you can use google with keywords like "BGP convergence". But, I should show you an extreme example. That is, if we have only 1 AS, there is no convergence problem of BGP.
(I run Corporate Networks with routing table sizes >> Internet DFZ due to /32 announcements and such stuff, no BGP Problems on good setups.)
Convergence heavily depends on your policy. Masataka Ohta
On Monday 08 May 2006 07:28, Florian Weimer wrote:
* Gert Doering:
Which is touching the core of the problem:
"can we agree upon who should be allowed to put a route into my routers"?
Ideally, that would be someone who pays for this kind of service. The fewer prefixes there are, the more feasible this approach will be. 8-)
To be routed one needs at least one relationship with an ISP (in whatever form). My organization has PI (and PA) space. The PI space used to be routed via DRA (UK) via a milnet to the US, later via NL-Net, later via UU-net and now via Surfnet. In all occasions we pay for the service to be routed. Now how our provider(s) arrange with their peers to get our blocks routed is their business but I assume there is some form of agreement that takes care of it. So it is not like PI users just connect to the net for free. The fee be able to add routes is in what one pays to the connectivity provider. The use of PI space also implies that the PI holder can't just order a DSL from somewhere and get it routed. To get PI routed one needs a more serious contract (like we have) but that's ok because PI is part of a business continuity plan and one looks at the business case. The connectivity provider (generally an ISP) has to make sure all other parties are happy. That's the role of an ISP. In my view, regardless if one pays for the right to use a PI block, the fact that a PI holder has one does not load it into the routing table. Being connected does. Being connected is not free and costs money and is provided by ISP's or other organizations that connect somehow to the core of the Internet. [..] -- Marc van Selm NATO C3 Agency CIS Division E-mail: marc.van.selm@nc3a.nato.int (PGP capable)
I think this idea is no better than standard redundancy (multiple lines to the same ISP). Actually, I think it is worse since it is required of you to either stay in the city or stretch a long fibre to it should you move all or some of your stuff to another. Companies will try to do the latter because they don't want to change their IP.
Most companies do not move to another city. But if they do, then the cost of long distance backhaul will likely drive them to renumber their networks to the new city's aggregate. Every situation will have corner cases that don't appear to fit the mold. But, if we introduce geo-topo addressing as an ALTERNATIVE to classical provider addressing, then corner cases are less of a problem because there are two types of address. Sometimes classical PA will work better and sometimes GEO-TOPO will work better.
* Enterprises with "real" need of multi-homing having multiple uplinks to multiple ISPs and their own AS number.
Others have pointed out how this category is likely to grow a lot as Internet infrastructure becomes more and more important.
Couldn't the companies that _need_ PI multi-homing for redundancy reasons, these enterprises, create an ISP and get their "multi-homing" there instead?
Yes. But RIR policy should not force people to adopt this business model. Policy should give people the flexibility to adopt the business model that is right for them. --Michael Dillon
On Thursday 20 April 2006 15:48, Pekka Savola wrote:
Hi,
I don't support PI space to end-sites. We have to get rid of the notion that a random end-site has any business whatsoever in mucking with the global routing tables, either by making it much larger than need be or by polluting it with needless dynamicity.
Example of the latter: deploying inbound traffic engineering adjustment solutions which result in thousands of daily flaps in the advertisements, as shown by Huston's analysis.
We have way too much trouble with clueless ISPs to also add (or continue to add) end-sites to the mix...
Sorry I can't agree with you there. Organizations that really need this are generally very professional (ok not always but they they can hire a professional for them) and many times much larger than some ISPs. I think it is unfair to say that a non-ISP business is per definition not able to handle routing networks. I have just seen the 2nd fully uncordinated, but promissed to be smooth, transition of network connectivity by a large ISP in NL so I guess we all make mistakes. Could we leave emotions and kingdoms out of the discussion and focus on the real issue of a large network that happens not to be an ISP that needs solid connectivity to the net and has a large world-wide internal network managed by professionals.... Best regards, Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies.
Hi, On Mon, Apr 24, 2006 at 09:19:18AM +0200, Marc van Selm wrote:
Sorry I can't agree with you there. Organizations that really need this are generally very professional (ok not always but they they can hire a professional for them) and many times much larger than some ISPs. I think it is unfair to say that a non-ISP business is per definition not able to handle routing networks. I have just seen the 2nd fully uncordinated, but promissed to be smooth, transition of network connectivity by a large ISP in NL so I guess we all make mistakes. Could we leave emotions and kingdoms out of the discussion and focus on the real issue of a large network that happens not to be an ISP that needs solid connectivity to the net and has a large world-wide internal network managed by professionals....
This is actually what I see as the major point in the "PI policy" - figure out who really "needs" it -- and I can agree that there are many networks that would qualify, "being large enough, competent enough, and important[1] enough". Speaking as a network operator (not as WG co-chair) I would be fairly unhappy with a PI policy that permits "about anyone" to get PI - because PI is very unbalanced regarding "who benefits, and who pays for it". [1] yes, "important enough" is very difficult to measure. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Monday 24 April 2006 09:28, Gert Doering wrote:
Hi,
On Mon, Apr 24, 2006 at 09:19:18AM +0200, Marc van Selm wrote:
Sorry I can't agree with you there. Organizations that really need this are generally very professional (ok not always but they they can hire a professional for them) and many times much larger than some ISPs. I think it is unfair to say that a non-ISP business is per definition not able to handle routing networks. I have just seen the 2nd fully uncordinated, but promissed to be smooth, transition of network connectivity by a large ISP in NL so I guess we all make mistakes. Could we leave emotions and kingdoms out of the discussion and focus on the real issue of a large network that happens not to be an ISP that needs solid connectivity to the net and has a large world-wide internal network managed by professionals....
This is actually what I see as the major point in the "PI policy" - figure out who really "needs" it -- and I can agree that there are many networks that would qualify, "being large enough, competent enough, and important[1] enough".
Speaking as a network operator (not as WG co-chair) I would be fairly unhappy with a PI policy that permits "about anyone" to get PI - because PI is very unbalanced regarding "who benefits, and who pays for it".
True you have a good point here that is worth exploring. So how do we seperate then the "about anyone" from "those that need". I personally do not think the community should judge than one has a need and try to cast that in stone in some form of policy. But one could demand a sound justication in the request for PI that describes why PI is vital/important. This is to be judged by the RIR. Would adjusting the policy in that direction make sense? I know that this will take resourses of the RIR but I think it is fair that the requester should pay for that. Marc van Selm -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies.
Hi, On Mon, Apr 24, 2006 at 09:40:35AM +0200, Marc van Selm wrote:
Speaking as a network operator (not as WG co-chair) I would be fairly unhappy with a PI policy that permits "about anyone" to get PI - because PI is very unbalanced regarding "who benefits, and who pays for it".
True you have a good point here that is worth exploring.
So how do we seperate then the "about anyone" from "those that need".
Can't say.
I personally do not think the community should judge than one has a need and try to cast that in stone in some form of policy. But one could demand a sound justication in the request for PI that describes why PI is vital/important. This is to be judged by the RIR. Would adjusting the policy in that direction make sense? I know that this will take resourses of the RIR but I think it is fair that the requester should pay for that.
I understand what you're aiming for, but the problem is - the RIRs system doesn't work that way. The RIRs enforce the policy that the community (*we*) agree upon. Consider the RIRs "the executive arm of the community will" - so we need to provide clear guidance to the RIRs on "what's ok" and "what's not ok" - otherwise the hostmasters need to make up rules, and people will find themselves quite surprised at the outcome "now *that* is not what we imagined". Specifically in this case: the RIRs don't look at our routes, don't feel the pain of "too many routes", can't decide on "what will ISPs route?", and so on. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 92315 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Marc van Selm wrote: As a person who deeply interacted with IETF multihoming issues, I can understand you.
Sorry I can't agree with you there. Organizations that really need this are generally very professional (ok not always but they they can hire a professional for them) and many times much larger than some ISPs. I think it is unfair to say that a non-ISP business is per definition not able to handle routing networks.
Exactly. To the Internet, yahoo and google, for example, are a lot more important and generate a lot more traffic than some tier 1 ISP. However, it is also true that PI space is evil to explode routing tables. So, the only fair solution is to allow anyone qualify as an ISP and make ISP addresses dependent to upper layer ISP addresses. And, let major ISPs chances to get PI space through auction or other fair methods. If PI space MUST be scares, let it be scares even for ISPs. It should be noted that even though I wrote an ID for multi6 WG that BGP-style policy control works even for ISPs with non-PI addresses, I was never given any chance of discussion by the WG chairs, Brian and Kurt, at that time. IMHO, at least 1000 ISPs should be allowed to have the top level PI addresses. If renumbering is so painful and fairness is still required, even top level ISPs with PI space should also be forced renumbering. Masataka Ohta
On 24 apr 2006, at 14.16, Masataka Ohta wrote:
It should be noted that even though I wrote an ID for multi6 WG that BGP-style policy control works even for ISPs with non-PI addresses, I was never given any chance of discussion by the WG chairs, Brian and Kurt, at that time.
Isn't this what you presented here http://www3.ietf.org/proceedings/ 03nov/index.html - kurtis -
On Mon, Apr 24, 2006 at 09:16:23PM +0900, Masataka Ohta wrote:
If renumbering is so painful and fairness is still required, even top level ISPs with PI space should also be forced renumbering.
Very good point. Actually, only true "tier 1" ISPs (those with no default routing and all external connections being either peers or customers... every ISP tech will understand what I mean, but this definition hair can be spliced infinitely) really _need_ PI. ALL others can use PA. This would bring the DFZ down to a very small 2-figure count of routes. :-) That's the only real fundamental NEED we can identify. All the other "needs" are luxury... and we would debating whom we allow this luxury and whom we do not. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Mon, 24 Apr 2006, Daniel Roesen wrote:
On Mon, Apr 24, 2006 at 09:16:23PM +0900, Masataka Ohta wrote:
If renumbering is so painful and fairness is still required, even top level ISPs with PI space should also be forced renumbering. Very good point. Actually, only true "tier 1" ISPs (those with no default routing and all external connections being either peers or customers... every ISP tech will understand what I mean, but this definition hair can be spliced infinitely) really _need_ PI. ALL others can use PA. This would bring the DFZ down to a very small 2-figure count of routes. :-) <snip>
Combine this with geoip one way or another and we have something that should solve all multihoming/PI problems as I see it... But do we really want to put all our routes in the hand of a very few ISP's? That's the only problem. Another way of doing this, "tier 1" within a RIR justify a PI allocation? -- ------------------------------ Roger Jorgensen | roger@jorgensen.no | - IPv6 is The Key! -------------------------------------------------------
Roger Jorgensen wrote:
If renumbering is so painful and fairness is still required, even top level ISPs with PI space should also be forced renumbering.
Very good point. Actually, only true "tier 1" ISPs (those with no default routing and all external connections being either peers or customers... every ISP tech will understand what I mean, but this definition hair can be spliced infinitely) really _need_ PI. ALL others can use PA. This would bring the DFZ down to a very small 2-figure count of routes. :-)
Combine this with geoip one way or another and we have something that should solve all multihoming/PI problems as I see it... But do we really want to put all our routes in the hand of a very few ISP's? That's the only problem.
Doing so is as bad as frequency band auction in Europe. So, let the number of possible tier 1s larger. However, so large number of ASes means so slow convergence time of BGP, which is already unacceptable (though some of you might think the Internet can not be used for mission critical purposes that minutes or tens of minutes of convergence time is fine) with IPv4 Internet today. Thus, my suggestion in <draft-ohta-multihomed-isps-00.txt> WAS: The proper number of TLAs, it seems to the author, should be somewhere between 1024 and 8192. Masataka Ohta
participants (32)
-
Bernhard Schmidt -
Daniel Roesen -
David Conrad -
Davis, Terry L -
Dennis Lundström -
Florian Weimer -
Geoff Huston -
Gert Doering -
Jeroen Massar -
Joao Damas -
Jørgen Hovland -
Kurt Erik Lindqvist -
Lea Roberts -
leo vegoda -
Marc van Selm -
Marshall Eubanks -
Masataka Ohta -
Max Tulyev -
Max Tulyev -
Maxim V. Tulyev
-
Michael.Dillon＠btradianz.com -
Nick Hilliard -
Nils Ketelsen -
Oliver Bartels -
Owen DeLong -
Pekka Savola -
Per Heldal -
Robert E.Seastrom -
Roger Jorgensen -
Sascha Lenz -
Sascha Luck -
Sascha Luck -
Scott Leibrand -
Stephen Sprunk -
Steve Feldman -
Tim Chown -
Tim Streater -
Wilfried Woeber, UniVie/ACOnet