Proposal 2011-02 moving to Last Call
Hello working group, After a extensive analysis of the discussions on the mailing list about proposal 2011-02 we have come to the conclusion that we have rough consensus on this policy proposal, and we have decided to move this policy proposal to Last Call. We have seen much support for this proposal on the mailing list. On the other hand we have seen concern about accelerated growth of the routing table caused by implementing this policy. Data from other RIRs that have a more liberal IPv6 PI policy have not shown evidence for excessive growth in IPv6 PI assignments. As of today, Sep 23, there are 2420 /48 routes in the global BGP table, compared to 3600 /32 routes and ~1100 routes of other prefix lengths. Based on this data we consider the arguments agains this proposal based on possible routing table growth as addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space. The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. If this policy proposal has consensus at the end of Last Call we will also ask the RIPE NCC to monitor and regularly report on IPv6 PI assignment statistics so we can see if the number of PI requests runs out of bounds. On behalf of the Address Policy WG chairs, Sander Steffann
Dear address-policy-wg, Sander, I'm glad to hear that a rough consensus has been achieved, and would like to reaffirm my support for this policy proposal. -- Respectfully yours, David Monosov On 09/23/2011 02:15 PM, Sander Steffann wrote:
Hello working group,
After a extensive analysis of the discussions on the mailing list about proposal 2011-02 we have come to the conclusion that we have rough consensus on this policy proposal, and we have decided to move this policy proposal to Last Call.
We have seen much support for this proposal on the mailing list. On the other hand we have seen concern about accelerated growth of the routing table caused by implementing this policy. Data from other RIRs that have a more liberal IPv6 PI policy have not shown evidence for excessive growth in IPv6 PI assignments. As of today, Sep 23, there are 2420 /48 routes in the global BGP table, compared to 3600 /32 routes and ~1100 routes of other prefix lengths. Based on this data we consider the arguments agains this proposal based on possible routing table growth as addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space. The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space. If this policy proposal has consensus at the end of Last Call we will also ask the RIPE NCC to monitor and regularly report on IPv6 PI assignment statistics so we can see if the number of PI requests runs out of bounds.
On behalf of the Address Policy WG chairs, Sander Steffann
On 23/09/2011 13:15, Sander Steffann wrote:
addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space.
Sander, I didn't see this mentioned in the policy proposal. Could you explain how this requirement was reached in a way which is compatible with the RIPE Policy Development Process - i.e. by consensus and in a transparent manner? Nick
Hi Nick,
addressed. We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space.
I didn't see this mentioned in the policy proposal. Could you explain how this requirement was reached in a way which is compatible with the RIPE Policy Development Process - i.e. by consensus and in a transparent manner?
Someone suggested to include such documentation in IPv6 PI requests. Because this is not actually a policy change (it doesn't change if someone gets the address space or not) but an implementation issue we decided to add it as a note to the RIPE NCC. - Sander
On 23/09/2011 14:24, Sander Steffann wrote:
Someone suggested to include such documentation in IPv6 PI requests. Because this is not actually a policy change (it doesn't change if someone gets the address space or not) but an implementation issue we decided to add it as a note to the RIPE NCC.
I certainly suggested it as a policy possibility:
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00820....
Not sure if others talked about it too. However, there is a substantial difference between "explicitly required to provide evidence" and "to ask for extensive documentation" - the former was suggested because it does materially change the policy. Nick
Hello Nick,
Someone suggested to include such documentation in IPv6 PI requests. Because this is not actually a policy change (it doesn't change if someone gets the address space or not) but an implementation issue we decided to add it as a note to the RIPE NCC.
I certainly suggested it as a policy possibility:
http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00820....
Not sure if others talked about it too.
However, there is a substantial difference between "explicitly required to provide evidence" and "to ask for extensive documentation" - the former was suggested because it does materially change the policy.
I know, but that would change the IPv6 PI policy into a judgement call by an IPRA. That would make the policy unimplementable. The information would still be interesting though, which is why I suggest to the RIPE NCC that they ask for it anyway. It's just a suggestion. We don't tell the NCC how to implement policy, but we can suggest :-) Thanks, Sander
On 23/09/2011 14:38, Sander Steffann wrote:
I know, but that would change the IPv6 PI policy into a judgement call by an IPRA. That would make the policy unimplementable. The information would still be interesting though, which is why I suggest to the RIPE NCC that they ask for it anyway. It's just a suggestion. We don't tell the NCC how to implement policy, but we can suggest :-)
I admit that drawing the line between policy and implementation is a difficult issue, and that there are tensions between the two requirements. On the one hand, IPRAs get quite vague policies from ap-wg and would often like more clarity because they have a job to do and interpreting policy can sometimes be difficult. On the other hand, ap-wg tends to prefer to prescribe general principles and let the IPRAs do what seems sensible because they don't always have a clear picture of exactly the sort of requests that the IPRAs have to deal with. Hey, you can't legislate for every eventuality. Enough philosophy. There are two things that concern me here: 1. in this situation, I made a suggestion to add something to the policy and the proposers didn't put it into the policy and that's fine (I'm not hung up on 2011-02 and really want to see some form of IPv6 PI appear soon, and I'm particularly not hung up on the suggestion I made). However, someone blinked and now it's implicitly a part of the policy even though it wasn't part of the policy before. 2. if interpretation is implicitly added to a policy without it being explicitly stated, then the APWG is creating an expectation that the RIPE NCC will listen to this interpretation. I don't agree that it's just a suggestion: if there was no expectation that the NCC wasn't going to listen to it, the suggestion wouldn't have been made in the first place. Look, I really don't want to make this sound like bureaucratic ant abuse, but something has effectively been added to the policy outside the terms of the PDP and there is a problem with this. This is not a 2011-02 problem, but a PDP problem. Let's go ahead with 2011-02 as originally stated in the policy proposal - without the extra interpretation. Nick
Let's go ahead with 2011-02 as originally stated in the policy proposal - without the extra interpretation.
Agreed, Sander
On Fri, Sep 23, 2011 at 4:12 PM, Sander Steffann <sander@steffann.nl> wrote:
Let's go ahead with 2011-02 as originally stated in the policy proposal - without the extra interpretation.
Agreed, Sander
Great, thanks for resolving this. Regards, Martin (... and I approve of this message)
On Fri, 23 Sep 2011, Martin Millnert wrote:
On Fri, Sep 23, 2011 at 4:12 PM, Sander Steffann <sander@steffann.nl> wrote:
Let's go ahead with 2011-02 as originally stated in the policy proposal - without the extra interpretation.
Agreed, Sander
Great, thanks for resolving this.
Regards, Martin (... and I approve of this message)
Indeed. Do we see som light in the tunnel eventually? ;-) Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm
On Fri, Sep 23, 2011 at 04:12:46PM +0200, Sander Steffann wrote:
Let's go ahead with 2011-02 as originally stated in the policy proposal - without the extra interpretation.
Agreed, Sander
Under that provision, I do fully support the proposal 2011-02. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, I can not support this policy unless explicit restrictions added. 1, If the number of IPv6 PI slots allocated reaches a certain level then the policy should be immediatly reviewed; The number of the IPv6 PI slots allocated must not exceed the numbers of the LIRs in the regions; however, a lower limit would be also fine for me. 2, The policy should include the warning that ISPs might filter off the announcements of small sized slots from their routing table. Thanks, Géza
On 28/09/2011 15:45, Turchanyi Geza wrote:
1, If the number of IPv6 PI slots allocated reaches a certain level then the policy should be immediatly reviewed; The number of the IPv6 PI slots allocated must not exceed the numbers of the LIRs in the regions; however, a lower limit would be also fine for me.
I don't think there is a requirement to force a review at a particular number of registrations. Géza, if you disagree with this, there is nothing to stop you from submitting a new policy proposal when the number of ipv6 pi registrations reaches whatever level you believe is sufficient.
2, The policy should include the warning that ISPs might filter off the announcements of small sized slots from their routing table.
This is already in the policy: http://www.ripe.net/ripe/docs/ripe-523#routability Nick
Hi Géza,
1, If the number of IPv6 PI slots allocated reaches a certain level then the policy should be immediatly reviewed; The number of the IPv6 PI slots allocated must not exceed the numbers of the LIRs in the regions; however, a lower limit would be also fine for me.
That is not how the policy development process works. Anybody can submit a policy proposal at any time. We don't define specific points in time or arbitrary numbers at which we do policy reviews or changes. On the other hand: such a change is not needed. You can initiate such a review yourself at any time you want. This mailing list is always available for discussing/reviewing policies. We will make sure that we will have reports from the RIPE NCC to use as the basis for this. The line about routability applies to all address space, not only PI space. A warning about this is already included in the existing policy text. Thanks, Sander Steffann
Sander,
That is not how the policy development process works. Anybody can submit a policy proposal at any time.
i do not believe this reflects the full wisdom and history of the PDP. There is a difference between opening the flood gates and then starting another proposal to get them closed and opening the flood gates and determining in advance that they be closed once the dam reservoir is half full (or ~ empty). Both are possible under the PDP and i'd suggest that 2009-03 might well serve as a precedent for such a "dynamic" policy. -Peter (not taking any position w.r.t. the policy proposal or Geza's remark)
On Wed, 28 Sep 2011, Peter Koch wrote:
i do not believe this reflects the full wisdom and history of the PDP. There is a difference between opening the flood gates and then starting another proposal to get them closed and opening the flood gates and determining in advance that they be closed once the dam reservoir is half full (or ~ empty). Both are possible under the PDP and i'd suggest that 2009-03 might well serve as a precedent for such a "dynamic" policy.
I fear DFZ bloat. I have a hard time imagining that the policy group would change the PI policy even if there were an PI rate explosion, because of vested interest in keeping the policy in place from a large volume of people. I would feel a lot more ease at mind if there were some kind of provision in it that would actually put a cap on number of PI blocks and force an mandatory re-consideration (or review or what not) of the policy (even though this might pass anyhow because of the beforementioned vested interests). This can be put quite high, let's say 100k in 10 years for the RIPE region (I haven't put too much thought into the actual number). This would curb my doubts about it and I would fully support it, and the people saying there won't be a PI rate explosion shouldn't have much problem with it either, because if they're right, this provision would never come into effect. I also have no problem passing the current policy so we can change IPv6 PI rules, and discuss the actual cap number during the next coming months. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi Mikael,
I fear DFZ bloat. I have a hard time imagining that the policy group would change the PI policy even if there were an PI rate explosion, because of vested interest in keeping the policy in place from a large volume of people.
I would feel a lot more ease at mind if there were some kind of provision in it that would actually put a cap on number of PI blocks and force an mandatory re-consideration (or review or what not) of the policy (even though this might pass anyhow because of the beforementioned vested interests). This can be put quite high, let's say 100k in 10 years for the RIPE region (I haven't put too much thought into the actual number).
This would curb my doubts about it and I would fully support it, and the people saying there won't be a PI rate explosion shouldn't have much problem with it either, because if they're right, this provision would never come into effect.
I have serious doubts about setting an arbitrary cap and thereby creating 'fake' scarcity of a resource. It can also backfire: 'we see that things are going the wrong way, but we haven't reached the cap yet, so we'll wait until that happens'. The current PDP allows anyone to propose a policy change at any time, as soon as they see that something is wrong. I feel much more comfortable with that. But I am just a co-chair here. Decisions are made by the working group (everybody on this mailing list), not by me :-) If there is consensus that putting in a cap would be a good idea then that is what happens, and I'll give it my full support.
I also have no problem passing the current policy so we can change IPv6 PI rules, and discuss the actual cap number during the next coming months.
That would be great. Thanks, Sander Steffann
Hi, Thanks, Peter for your comments. Some people assumes that any change will be slow and we will have time to react. Perhaps we will have two years, as the policy development takes about two years. I do not think that this approach is safe enough. If the number of PI address space chunks exceed the number of LIRs than we might realise that the RIPE NCC works mostly for the PI address owners. Is this our intention? If RIPE would allow 100 000 PI route objects to be created and other RIR would do the same than the Internet would die very soon. OR: All ISP would filter of all PI annuoncements ;-) and all PI address would became totally useless. More route object not only mean more memories and perhaps new linecards/routers, however, also slow down of routing convergence. So, please be realistic, and formulate some realistic limits NOW. The numebr of LIRs served is just a hint, however, not a bad hint. Best, Géza
Hi Geza, I must admit that policy development has been very slow in some cases, but we also have had cases where the PDP was completed in months. But I see your point. But setting an arbitrary limit still feels wrong to me. How about taking this a bit further and reviewing policies regularly, like for example at every RIPE meeting? And we could review more than just the IPv6 PI policy... It will cause extra work for us as chairs, but it might be useful to do. - Sander
Hello Sander, many thanks for your proposal. On Thu, Sep 29, 2011 at 6:52 PM, Sander Steffann <sander@steffann.nl> wrote:
Hi Geza,
I must admit that policy development has been very slow in some cases, but we also have had cases where the PDP was completed in months. But I see your point.
Thanks.
But setting an arbitrary limit still feels wrong to me. How about taking this a bit further and reviewing policies regularly, like for example at every RIPE meeting? And we could review more than just the IPv6 PI policy...
It will cause extra work for us as chairs, but it might be useful to do.
- Sander
I still think it is better to set a limit with an educated guess and review it on the RIPE meeting... This would allow us fexibility while the process can not become uncontrolled. There will be no unforeseen side effects.... Thanks again, Géza
It's worth noting that a similar PI policy has been in place in the ARIN region for some time now, and has not resulted in any large increase in the IPv6 routing table. Just my .18 euros, Scott On Thu, Sep 29, 2011 at 9:22 AM, Turchanyi Geza <turchanyi.geza@gmail.com>wrote:
Hi,
Thanks, Peter for your comments.
Some people assumes that any change will be slow and we will have time to react. Perhaps we will have two years, as the policy development takes about two years.
I do not think that this approach is safe enough.
If the number of PI address space chunks exceed the number of LIRs than we might realise that the RIPE NCC works mostly for the PI address owners. Is this our intention?
If RIPE would allow 100 000 PI route objects to be created and other RIR would do the same than the Internet would die very soon. OR: All ISP would filter of all PI annuoncements ;-) and all PI address would became totally useless.
More route object not only mean more memories and perhaps new linecards/routers, however, also slow down of routing convergence.
So, please be realistic, and formulate some realistic limits NOW.
The numebr of LIRs served is just a hint, however, not a bad hint.
Best,
Géza
Hi, On Thu, Sep 29, 2011 at 11:42:59AM -0700, Scott Leibrand wrote:
It's worth noting that a similar PI policy has been in place in the ARIN region for some time now, and has not resulted in any large increase in the IPv6 routing table.
Yes. I have watched the global table fairly closely for the last years, and indeed, the number of PI routes in the global IPv6 table is well under control so far (and the rate it's growing is also under control). Slides up to May are in my RIPE62 IPv6 routing table report, but if it helps, I can go through the numbers and provide up-to-date graphs. Sander's announcement also had the most recent numbers of PA-vs-PI routes in it. Gert Doering -- just providing background data -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Thu, 29 Sep 2011, Gert Doering wrote:
Sander's announcement also had the most recent numbers of PA-vs-PI routes in it.
My worry horizon isn't the next 3years, it's the next 10-50 years. We need to enable renumbering and multihoming without DFZ slot for end entity, and easing PI requirements just makes the chance of this actually being implemented that much less likely. -- Mikael Abrahamsson email: swmike@swm.pp.se
Mikael Abrahamsson wrote: My worry horizon isn't the next 3 years, it's the next 10-50 years. We need to enable renumbering and multihoming without DFZ slot for end entity, and easing PI requirements just makes the chance of this actually being implemented that much less likely.
Sounds good, but you have it all backwards. The very reason we have IPv6 PI now is because easy renumbering and non-PI multihoming are red herrings. For the last 15 years, the IETF has lived on a lie that these features will be delivered. They have not. I hate to sound brutal, but why should I believe that you will find the Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming. Stop the vaporware. What you want does not exist. Unlike the IETF, ARIN has recognized that fact, and this is why we have IPv6 PI; it does not fulfill the initial IPv6 dream of a strongly aggregated, PA-only routing table but it's the best we have today. I'm tired of hearing "we need to". I have been hearing this for 15 years, enough of this. Oh, BTW, I tried too. You don't have anything; when you do, deliver it and come back to us. Michel.
On Thu, Sep 29, 2011 at 10:13:04PM -0700, Michel Py wrote:
Mikael Abrahamsson wrote: My worry horizon isn't the next 3 years, it's the next 10-50 years. We need to enable renumbering and multihoming without DFZ slot for end entity, and easing PI requirements just makes the chance of this actually being implemented that much less likely.
I hate to sound brutal, but why should I believe that you will find the Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming.
Michel.
DFZ slots are for those who pay for them... /bill
DFZ slots are for those who pay for them...
until i see where the actual monetary trading market is for so-called dfz slots, i call this bs randy
On Fri, Sep 30, 2011 at 03:26:32PM +0900, Randy Bush wrote:
DFZ slots are for those who pay for them...
until i see where the actual monetary trading market is for so-called dfz slots, i call this bs
randy
at the mo, this is not a specific line item on the bill but I (and I suspect this is true for many of us) pay someone to carry my traffic. implicit in that payment is the use of routing table slots. so it may be BS to you, but not to me, my account manager, or my bank. as usual, YMMV /bill
DFZ slots are for those who pay for them... until i see where the actual monetary trading market is for so-called dfz slots, i call this bs at the mo, this is not a specific line item on the bill but I (and I suspect this is true for many of us) pay someone to carry my traffic. implicit in that payment is the use of routing table slots.
and the socks their marketing folk wear, and the paint on their office walls, and the bog paper in their loo. randy
On Fri, Sep 30, 2011 at 11:42:49PM +0900, Randy Bush wrote:
DFZ slots are for those who pay for them... until i see where the actual monetary trading market is for so-called dfz slots, i call this bs at the mo, this is not a specific line item on the bill but I (and I suspect this is true for many of us) pay someone to carry my traffic. implicit in that payment is the use of routing table slots.
and the socks their marketing folk wear, and the paint on their office walls, and the bog paper in their loo.
randy
My, you certainly have / trak much more info that I care to... /bill
Michel Py wrote: I hate to sound brutal, but why should I believe that you will find the Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming.
Bill Manning wrote: DFZ slots are for those who pay for them...
This is not the way I see it. Paying for DFZ slots is embedded in "cost of doing business" for large / T1 ISPs, and in the recurring charges they charge to smaller ISPs or customers. If there was a monetary value, it would be relatively easy to collect a fee based on the number of prefixes announced upstream. I do not see that happening. It's all about money. The collective cost of announcing a prefix in the DFZ is less than the collective cost of having a complex and impossible to troubleshoot multihoming mechanism based on PA. As long as a DFZ slot does not cost $100 or $1000 a month, organizations will not go for a more complex mechanism. We are several orders of magnitude below the cost threshold. As of ID/LOC schemes, there is this myth that the table is small but in practice large environments will have to maintain a very large ID/LOC map which brings us back to the size of the DFZ again. Michel.
Michel, On Sat, Oct 1, 2011 at 8:36 PM, Michel Py < michel@arneill-py.sacramento.ca.us> wrote:
Michel Py wrote: I hate to sound brutal, but why should I believe that you will find the Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming.
Bill Manning wrote: DFZ slots are for those who pay for them...
This is not the way I see it. Paying for DFZ slots is embedded in "cost of doing business" for large / T1 ISPs, and in the recurring charges they charge to smaller ISPs or customers. If there was a monetary value, it would be relatively easy to collect a fee based on the number of prefixes announced upstream. I do not see that happening.
It's all about money. The collective cost of announcing a prefix in the DFZ is less than the collective cost of having a complex and impossible to troubleshoot multihoming mechanism based on PA. As long as a DFZ slot does not cost $100 or $1000 a month, organizations will not go for a more complex mechanism. We are several orders of magnitude below the cost threshold.
I would like to see your calculation. How many line cards have you included? My rough estimation would be about 300 000 line cards today, but is is realy rough, actually I guessed on the AS numbers, multiplied by a not to high constant. DFZ slots must include not only the routers, but the cost of the slowing down of the convergence. This is an issue for all of us. Unfortunately the shortage of the IPv4 space will increase the DFZ already at the IPv4 level. Let us not to create more burden at this stage of the transition. Géza
Actually, today is not: http://labs.ripe.net/Members/gih/routing-2011 But let's see in a few months. /as On 1 Oct 2011, at 17:47, Turchanyi Geza wrote:
Unfortunately the shortage of the IPv4 space will increase the DFZ already at the IPv4 level. Let us not to create more burden at this stage of the transition.
Géza
Hello Arturo, many thanks for your link! On Sat, Oct 1, 2011 at 10:53 PM, Arturo Servin <aservin@lacnic.net> wrote:
Actually, today is not:
http://labs.ripe.net/Members/gih/routing-2011
But let's see in a few months.
/as
On 1 Oct 2011, at 17:47, Turchanyi Geza wrote:
Unfortunately the shortage of the IPv4 space will increase the DFZ already at the IPv4 level. Let us not to create more burden at this stage of the transition.
I expects increase in the number of the entires in DFZ due to address block
trading, splitting... Thanks, Géza
On Oct 1, 2011, at 8:36 AM, Michel Py wrote:
As of ID/LOC schemes, there is this myth that the table is small but in practice large environments will have to maintain a very large ID/LOC map which brings us back to the size of the DFZ again.
The timescales within which lookups in an ID/LOC map must occur are a bit different than those in a FIB. Regards, -drc
On Sat, Oct 01, 2011 at 10:50:59AM -1000, David Conrad wrote:
On Oct 1, 2011, at 8:36 AM, Michel Py wrote:
As of ID/LOC schemes, there is this myth that the table is small but in practice large environments will have to maintain a very large ID/LOC map which brings us back to the size of the DFZ again.
The timescales within which lookups in an ID/LOC map must occur are a bit different than those in a FIB.
Regards, -drc
Two words... PRE FETCH /bill
Michel Py wrote: As of ID/LOC schemes, there is this myth that the table is small but in practice large environments will have to maintain a very large ID/LOC map which brings us back to the size of the DFZ again.
David Conrad wrote: The timescales within which lookups in an ID/LOC map must occur are a bit different than those in a FIB.
This is true, but put it back in prospective: the ID/LOC map may gain another order of magnitude. So may Moore's law over a few years, and we're back to square one. Think about it as the TCP sliding window: ID/LOC skews the window a bit, but the gain obtained is questionable compared to the loss due to the increased complexity. How good does it do to you to optimize 100Mbit Ethernet when it is cheaper to build GigE? I'm not saying I like it, but that's the way it is. Simplicity is priceless. Michel.
Hi Michel and David, I like a technical discussion about scaling routers probably as much as you, however that is a bit outside the scope of the suggested policy I think. The policy proposal is to get it in line with v4 and also ARIN is having a similar policy. For companies that don't want to deal with the multi-homing requirement currently sign up to become a LIR. This particular part of the v6 policy (the multi-homing requirement) has been an issue for while already and it needs to be fixed. Although nobody can look into the future, experience from the ARIN region, figures from RIPE on PI (v4 and v6) in the DFZ, the supplied de-aggregation info, it doesn't show that with this policy the routing table will explode. As I also stated in my presentation on RIPE 62 in Amsterdam on 2011-02, currently it is a financial discussion for an end-customer, not a technical one. An end-customer can already decide for v6 without the multi-homing requirement, but somehow an end-customers that can't become a LIR or don't see themselves as an ISP, can't deploy v6 because they have no multi-homed network setup. There are people unlike ourselves, that just don't want to deal with the RIPE 'stuff' and are happy to leave that up to others if they can. Will this policy open the gates for everything to start requesting everything they like ? No. There are still other limitations in v6 that we don't see in v4 (like restrictions for colocation or DSL/access address usage, sub-allocation etc. ) You still need PA for those kind of requests. Kind regards, Erik Bais
Erik Bais wrote: Hi Michel and David, I like a technical discussion about scaling routers probably as much as you, however that is a bit outside the scope of the suggested policy I think.
It is, guilty as charged. I apologize. I support the policy. Anything that can facilitate IPv6 deployment today has to be done, regardless of long-term consequences and even if it means establishing precedents that nobody really likes. Michel.
On 01/10/2011 19:36, Michel Py wrote:
It's all about money. The collective cost of announcing a prefix in the DFZ is less than the collective cost of having a complex and impossible to troubleshoot multihoming mechanism based on PA. As long as a DFZ slot does not cost $100 or $1000 a month, organizations will not go for a more complex mechanism. We are several orders of magnitude below the cost threshold.
Can we move past this notion of charging for DFZ slots? There is no practical way of doing it and constantly harping on about it is pointless and distracting. Nick
On Thu, 29 Sep 2011, Michel Py wrote:
I hate to sound brutal, but why should I believe that you will find the Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming.
I am well aware of this.
Stop the vaporware. What you want does not exist. Unlike the IETF, ARIN
I never said it did.
I'm tired of hearing "we need to". I have been hearing this for 15 years, enough of this. Oh, BTW, I tried too. You don't have anything; when you do, deliver it and come back to us.
We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes. So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution. We know it's bad, we still use it because there is no better way right now. That doesn't mean we should give up. It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much. But let's get IPv6 implemented, a few hundred thousand more routes doesn't really matter, as long as they don't turn into many millions. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, [...]
We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes.
While this might be true indeed - in the long term - it also might be possible that - in the long term - it does scale by some magic trick of some very intelligent maths person and some cool vendor. So we're only guessing here. At the moment you're certainly right.
So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution. We know it's bad, we still use it because there is no better way right now. That doesn't mean we should give up.
It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much.
But let's get IPv6 implemented, a few hundred thousand more routes doesn't really matter, as long as they don't turn into many millions.
I think the problem is not (yet) the total amount of prefixes, but the rate of growth. As long as the tables don't grow too fast, i think there is not so much of a problem since the vendors can keep up with this and companies can plan for upgrades. If the tables grow too fast, this will be indeed a bigger problem, but there are no signs yet that this will happen (in the IPv6 tables at least, not so sure about IPv4 tables post depletion with all the expected fragmentations :-/ ). But again, just my 0.02EUR on this, also only educated guesses here based on the numbers we have seen. Bottom line: It's nothing we need to discuss or make into policy at this very moment. We just need to keep an eye on it, and i'm sure we will. I'm very certain that the majority of the community will agree to another policy as soon as the majority does have a problem with the size of the tables. For the moment, i just see the majority having problems with the current asymmetric IPv4 + IPv6 PI policies, and that's what this policy draft is about, nothing else. I'm a bit disappointed that this one is hijacked and used for general PI policy discussions over and over. I really would suggest writing another, general (IPv4+IPv6) policy draft for this and discuss these long-term issues there. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hi Mike, On Fri, Sep 30, 2011 at 7:36 AM, Mikael Abrahamsson <swmike@swm.pp.se>wrote:
On Thu, 29 Sep 2011, Michel Py wrote:
I hate to sound brutal, but why should I believe that you will find the
Holy Grail that everyone else has been searching for over the last 15 years? I heard it all, I wrote part of it. There is NO solution to make renumbering easy and there is NO solution nearly as good as PI for multihoming.
I am well aware of this.
Stop the vaporware. What you want does not exist. Unlike the IETF, ARIN
I never said it did.
I'm tired of hearing "we need to". I have been hearing this for 15 years,
enough of this. Oh, BTW, I tried too. You don't have anything; when you do, deliver it and come back to us.
We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes.
So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution.
Yes, fully agree here.
We know it's bad, we still use it because there is no better way right now. That doesn't mean we should give up.
It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much.
But let's get IPv6 implemented, a few hundred thousand more routes doesn't really matter, as long as they don't turn into many millions.
I realy would like to know what makes you so optimistic? While you think so that a few hundred thousands more routes doesn!t really matter?
Which kind of routers/line cards could support this at wire speed? Any summary of convergence issues in large scale network? Am I missed some new technology that is already implemented allmost everywhere?
-- Mikael Abrahamsson email: swmike@swm.pp.se
I would be glad to receive additional information here, if this exists,
please share it! Many thanks, Géza
On Fri, 30 Sep 2011, Turchanyi Geza wrote:
I realy would like to know what makes you so optimistic? While you think so that a few hundred thousands more routes doesn!t really matter?
Which kind of routers/line cards could support this at wire speed? Any summary of convergence issues in large scale network?
As far as I know, Cisco 7600 with XL PFC, Juniper MX, Cisco ASR 9k, CRS etc, all handle 1M or more routes, or at least a mix of 0.5M IPv4 and 0.25k IPv6 routes. I don't see why number of IPv6 routes would converge a lot slower than number of IPv4 routes.
Am I missed some new technology that is already implemented allmost everywhere?
Prefix independent convergence, ie BGP prefix points to loopback which points to outgoing interface. When you need to converge your IGP you just rewrite the loopback pointers. This doesn't help EBGP of course, but number of routes are increasing slower tham moores law, so as long as the router vendors implement RIB processing in modern hw (not PPC :P), RIB handling is fine. Still, a lot of platforms can only program approximately 10k prefixes per second into hw, so increasing number of prefixes by hundreds of thousands means tens of seconds of increased convergence times for EBGP. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hello Mike, OK, then we see both the same, just the interpretation is different. Lets see the details. On Fri, Sep 30, 2011 at 10:09 AM, Mikael Abrahamsson <swmike@swm.pp.se>wrote:
On Fri, 30 Sep 2011, Turchanyi Geza wrote:
I realy would like to know what makes you so optimistic? While you think
so that a few hundred thousands more routes doesn!t really matter?
Which kind of routers/line cards could support this at wire speed? Any summary of convergence issues in large scale network?
As far as I know, Cisco 7600 with XL PFC, Juniper MX, Cisco ASR 9k, CRS etc, all handle 1M or more routes, or at least a mix of 0.5M IPv4 and 0.25k IPv6 routes. I don't see why number of IPv6 routes would converge a lot slower than number of IPv4 routes.
Am I missed some new technology that is already implemented allmost
everywhere?
So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow a few hundred thousands more IPv6 routes at all (not even would allow an 0.25M IPv6 limit) -- and speed of processing is an other issue...
Prefix independent convergence, ie BGP prefix points to loopback which points to outgoing interface. When you need to converge your IGP you just rewrite the loopback pointers.
This doesn't help EBGP of course, but number of routes are increasing slower tham moores law, so as long as the router vendors implement RIB processing in modern hw (not PPC :P), RIB handling is fine.
Still, a lot of platforms can only program approximately 10k prefixes per second into hw, so increasing number of prefixes by hundreds of thousands means tens of seconds of increased convergence times for EBGP.
Agreed. Convergence is an issue!!!
-- Mikael Abrahamsson email: swmike@swm.pp.se
In summary: we do not have the technology which would allow a very liberal PI allocation policy, therefore a very liberal PI allocation policy is not possible now. Strict limits must be kept. Thanks, Géza
On Fri, 30 Sep 2011, Turchanyi Geza wrote:
So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow a few hundred thousands more IPv6 routes at all (not even would allow an 0.25M IPv6 limit) -- and speed of processing is an other issue...
Huh? Hardwired? It's not fixed, it is either configurable or dynamic, depending on platform.
In summary: we do not have the technology which would allow a very liberal PI allocation policy, therefore a very liberal PI allocation policy is not possible now.
Yes. Current level of proposed "strictness" is ok for me right now, but I definitely believe it needs to be monitored closely. -- Mikael Abrahamsson email: swmike@swm.pp.se
On 30/09/2011 09:28, Turchanyi Geza wrote:
In summary: we do not have the technology which would allow a very liberal PI allocation policy, therefore a very liberal PI allocation policy is not possible now.
Strict limits must be kept.
I get the impression that people are talking about something which lies somewhere between "very liberal" and "strict limits". Nick
Hi, On Fri, Sep 30, 2011 at 03:26:11PM +0100, Nick Hilliard wrote:
On 30/09/2011 09:28, Turchanyi Geza wrote:
In summary: we do not have the technology which would allow a very liberal PI allocation policy, therefore a very liberal PI allocation policy is not possible now.
Strict limits must be kept.
I get the impression that people are talking about something which lies somewhere between "very liberal" and "strict limits".
Indeed, and to stress a point that Mikael has already made: even with that change, it's still not "single click" easy to get PIv6. PIv6 still needs application forms to be filled, a contract to be signed, and yearly fees to be paid - which shifts the balance somewhat away from "PIv6 is the easy way" (but if people have appropriate usage scenarios, it's still *possible* to get PIv6). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
It is time for PIv6 to become really as easy as * filling out the form (as one did for PIv4) * signing the contract (as one did for PIv4) * paying the fees (as one did for PIv4). I have seen people using SixXS tunnels to be more provider independent. Seriously! Tunneling the traffic of hosts/servers, who are IPv6 capable and well-konfigured through IPv4 is not what we want at all, is it? regards, Dan Luedtke -- danrl / Dan Luedtke http://www.danrl.de
Turchanyi Geza wrote: [...]
So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow a few hundred thousands more IPv6 routes at all (not even would allow an 0.25M IPv6 limit) -- and speed of processing is an other issue...
Even right now a large proportion of the router boxes on the Internet are *not* capable of dealing with the full routing table in the DFZ. This has been the case for many years already, btw. Still the 'net was and is pretty healthy and packets get shipped to the correct destination. [...]
Strict limits must be kept.
I still believe that it is the ISPs' job to manage the DFZ and to decide which prefixes to accept - or maybe not. I am pretty sure that the PI address blocks are taken from a well-documented space, so it is up to the (individual) ISP(s) to manage their routing environment. I do not see a mandate for the policy and/or the NCC to prohibit a (maybe small) number of participants from doing "the right thing" - from their point of view. In the very end, the money that keeps the IPSs going and earning money is coming from customers, isn't it? :-)
Thanks,
Géza
Cheers, Wilfried.
Hello Wilfried, On Mon, Oct 3, 2011 at 8:12 PM, Wilfried Woeber, UniVie/ACOnet < Woeber@cc.univie.ac.at> wrote:
Turchanyi Geza wrote: [...]
So the hardwired limit of 0.5M IPv4 routes and 0.25k IPv6 does not allow a few hundred thousands more IPv6 routes at all (not even would allow an 0.25M IPv6 limit) -- and speed of processing is an other issue...
Even right now a large proportion of the router boxes on the Internet are *not* capable of dealing with the full routing table in the DFZ. This has been the case for many years already, btw. Still the 'net was and is pretty healthy and packets get shipped to the correct destination.
Well, what you say is true, however, it is easy to interpret it in a wrong way. What I says: before accepteng a "principle", or policy, we should be able to understand, at least roughly, the financial consequences. I also says, that I seriously doubt that the PI space allocation should be "liberized" in order to push through the IPv6 deployment. The first real question, what will be, or might be the consequence if DFZ routing table growth further significantly. Please keep in your calculation that an IPv6 entry need twice as much address space in the routing table than an IPv4 entries. The conseqences are two folds: SLOW DOWN in the routing and forced upgrade of ALL routing cards that are able to support "only" 0,5M IPv4 routing entries AND are involved in DFZ zone handling. I think, it would be crucial to know how many router cards would be included in the Internet today. I made a very a rough estimation: 300 000 cards. Of course, there are much more cards in the backbones. May be I am wrong, however, please do not neglect this issue. Let's clarify first: roughly how many router cards MUST be upgraded if the typical 0,5M limit reached (counting twice en IPv6 enty). In parallel, we should better understand the slow-down consequences as well.
[...]
Strict limits must be kept.
The above mentionned limits are the strict limits, not to forget. http://labs.ripe.net/Members/gih/routing-2011 The picture of Geoff Huston shows that we are getting too close to the typical existing limits.
I still believe that it is the ISPs' job to manage the DFZ and to decide which prefixes to accept - or maybe not. I am pretty sure that the PI address blocks are taken from a well-documented space, so it is up to the (individual) ISP(s) to manage their routing environment.
NO, we should not dreams about policy blindly and we should not separate our knowledge and question marks.
I do not see a mandate for the policy and/or the NCC to prohibit a (maybe small) number of participants from doing "the right thing" - from their point of view.
We are responsible for the problems provoked by the grows of the Internet.
In the very end, the money that keeps the IPSs going and earning money is coming from customers, isn't it? :-)
Well, this statement might be read that my approach is not customer oriented enough. In opposite, it is. I do not want to suggest "solutions" for customers that would slow down the Internet and increase seriously the price of the service if these "solutions" would not be used just in very exeptional case. Slowing down the internet is not customer freindly at all. Increasing the service price would be? I am pretty sure that IPv6 PI space needed only in very exeptional cases, and I also pretty sure that we MUST say this to everybody clearly and without delay. Your freind since 20 years, Géza
On Tue, 4 Oct 2011, Turchanyi Geza wrote:
Let's clarify first: roughly how many router cards MUST be upgraded if the typical 0,5M limit reached (counting twice en IPv6 enty).
In parallel, we should better understand the slow-down consequences as well.
While I agree with you, this is way too late, and people don't generally care about this cost (at least not officially). RIPE is disconnected from routing, and the routing subsystem is not something people generally care about in this policy wg (my opinion). RIPE hands out addresses, they do not do routing. So let's make the IPv6 PI policy the same as IPv4 (remove multihoming) and then we monitor growth. When it hits 100k IPv6 PI (or some other number) prefixes, let's review again. My dystopian view is that this won't be fixed but instead vendors will have to create routers that can handle many million of routes in the next decades. This will cost a lot of money, but that might still be cheaper than trying to get smaller ISPs and enterprise to aquire and handle renumbering mechanisms that haven't even been developed yet. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Tue, 4 Oct 2011, Mikael Abrahamsson wrote:
My dystopian view is that this won't be fixed but instead vendors will have to create routers that can handle many million of routes in the next decades.
As they have done during the last 20+ years. This is the way of the Internet. If you want to be there - keep upgrading! Yes, it cost money. Big money. And if your business case does not include this - sorry, but then you have done a really bad job! /Jorgen
Mikael Abrahamsson wrote: My dystopian view is that this won't be fixed but instead vendors will have to create routers that can handle many million of routes in the next decades.
Indeed. And, somewhere at Cisco and Juniper, someone doesn't mind that this will require very expensive TCAM (or whatever comes next) in the forwarding plane and fancy ASICs to push packets at Terabit wire speed. That's what their business is about.
Jörgen Eriksson wrote: As they have done during the last 20+ years. This is the way of the Internet. If you want to be there - keep upgrading! Yes, it cost money. Big money. And if your business case does not include this - sorry, but then you have done a really bad job!
I will not be sorry. Buying out the customers of incapable competitors when they go belly up does not shock me. Michel.
Mikael Abrahamsson wrote: My dystopian view is that this won't be fixed but instead vendors will have to create routers that can handle many million of routes in the next decades.
Indeed. And, somewhere at Cisco and Juniper, someone doesn't mind that this will require very expensive TCAM (or whatever comes next) in the forwarding plane and fancy ASICs to push packets at Terabit wire speed. That's what their business is about.
Well... So far Cisco and Juniper have been able to piggyback their use of TCAM resources with what's available in the marketplace. From what I've picked up from reputable sources, we're pushing the limits, and Moore's law does not appear to apply to the rather specialized market of humungous TCAM chips. I'm not sufficiently of an optimist that I think we won't hit a technological limit in the case of us collectively injecting too much entropy into the global routing table. Therefore I've voiced my concerns over this proposal earlier, and I continue to hold this view. Regards, - Håvard
On 04/10/2011 18:14, Havard Eidnes wrote:
Well... So far Cisco and Juniper have been able to piggyback their use of TCAM resources with what's available in the marketplace. From what I've picked up from reputable sources, we're pushing the limits, and Moore's law does not appear to apply to the rather specialized market of humungous TCAM chips.
TCAM is not the only lookup system suitable for packet forwarding lookups: Juniper have been using RLDRAM II since 2007 (FCS of m120). And Cisco have started using RLDRAM in the ASR1000 packet processing engine. I'm not trying to understate how difficult this sort of thing is, btw. Packet forwarding engines are hard. Nick
Havard Eidnes wrote: From what I've picked up from reputable sources, we're pushing the limits, and Moore's law does not appear to apply to the rather specialized market of humungous TCAM chips. I'm not sufficiently of an optimist that I think we won't hit a technological limit in the case of us collectively injecting too much entropy into the global routing table.
Getting back to the policy part and not the technicalities of forwarding plane implementation: this is not the point. Keep in mind that part the very design of IPv6 is precisely the uncertainties around hitting a wall at some point. 10 years ago, I defended your position for the same reasons you do, and I am not among those saying that there is no risk, or that it will work the next 20 years the same way it worked the past 20. Nobody has a crystal ball. Here is the point: now the name of the game is no longer making it right, it's making it happen at all. We do not have the luxury of contemplating a 15 year deployment horizon anymore. What we are weighing in now are 2 opposite risks: the risk of hitting a wall in DFZ size in the future, against the risk of a total deployment failure. Michel.
On Wed, Oct 5, 2011 at 2:07 AM, Michel Py < michel@arneill-py.sacramento.ca.us> wrote:
Havard Eidnes wrote: From what I've picked up from reputable sources, we're pushing the limits, and Moore's law does not appear to apply to the rather specialized market of humungous TCAM chips. I'm not sufficiently of an optimist that I think we won't hit a technological limit in the case of us collectively injecting too much entropy into the global routing table.
Getting back to the policy part and not the technicalities of forwarding plane implementation: this is not the point.
Keep in mind that part the very design of IPv6 is precisely the uncertainties around hitting a wall at some point. 10 years ago, I defended your position for the same reasons you do, and I am not among those saying that there is no risk, or that it will work the next 20 years the same way it worked the past 20. Nobody has a crystal ball.
Here is the point: now the name of the game is no longer making it right, it's making it happen at all. We do not have the luxury of contemplating a 15 year deployment horizon anymore. What we are weighing in now are 2 opposite risks: the risk of hitting a wall in DFZ size in the future, against the risk of a total deployment failure.
Blowing up the DFZ zone wont accelerate the deployement of IPv6, in opposite, it will make harder to maintain the IPv4 service as well. The crucial points of the delay of IPv6 deployement are the following - load balancing at the content provision providers' site; - home network transition; - traffic monitoring at the entreprise, where the enterprise management would like to control and monitor, what is going on. For the later point the Obama administration defined a deadline of September 2012, if I remember well. There is a new working group at IETF for home network transition, started this summer. Unfortunatly the loadbalancing issues are vendor specifics. So these issues create delay, unfortunately. I still missed the arguments why would provide any help in the transition if PI allocations would be "liberized", just to be pleased for a small set of PI belivers? If PI belivers happen to complete their transition as the last ones, in two yeears -- should we care? Blowing up the DFZ is a big problem. It should not happen in the near future. Thanks, Géza
On Wed, 5 Oct 2011, Turchanyi Geza wrote:
I still missed the arguments why would provide any help in the transition if PI allocations would be "liberized", just to be pleased for a small set of PI belivers?
Well, there are many tens of thousands of them in the RIPE region alone, don't know if that can be called "small".
Blowing up the DFZ is a big problem. It should not happen in the near future.
If IPv6 PI follows IPv4 PI, it's not going to blow up in the near future. My worry is long term, not short term. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, Oct 5, 2011 at 11:39 AM, Mikael Abrahamsson <swmike@swm.pp.se>wrote: [..]
If IPv6 PI follows IPv4 PI, it's not going to blow up in the near future.
My worry is long term, not short term.
If the policy guaranties this, its OK. However, what is your guess: how many IPv4 routing entries will be the in the DFZ table in November 2011 and how many in November 2012? In November 2013? Roughly, in two years? What will slow down the growth? What might increase? How many IPv6 entries can be added if the total capacity of the line card is 0.5M IPv4 routing entry? Lets see: http://labs.ripe.net/Members/gih/BGPRoutingTable2011.png If there are no more IPv4 addresses to be allocated by the RIRs, the routing tably still will increase due to exchangeng (selling) slots of addresses. OK. if we would be able to stop the increase of the IPv4 address entries at 440 000 then we would have rooms for 30 000 IPv6 routing entries. 30 000 IPv6 entries are not too many, there are more AS in use today. Therefore it would be better to stop the increase at lower level - otherwise huge investment will be needed world wide soon. In the other hand if the small IP address slots would be very limited both at IPv4 and IPv6 level then the IPv4->IPv6 transition could be executed with the line cards capable to handle 0.5M IPv4 routes. Either we restrict ourself within a narrow lane or hugh investments AND toleration of SLOW DOWN is unavoidable. Best, Géza
-- Mikael Abrahamsson email: swmike@swm.pp.se
Turchanyi, It looks like we're circulating back to the same implementation-specific, 10-year-old-router-design arguments: On Wed, Oct 5, 2011 at 9:52 PM, Turchanyi Geza <turchanyi.geza@gmail.com> wrote:
On Wed, Oct 5, 2011 at 11:39 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
[..]
If IPv6 PI follows IPv4 PI, it's not going to blow up in the near future.
My worry is long term, not short term.
How many IPv6 entries can be added if the total capacity of the line card is 0.5M IPv4 routing entry?
If the capacity of any packet forwarding engine cannot fit X+Y route entries, it cannot fit X+Y route entries. Gotcha. While I speak only for myself, I think I dare say that your voice of reservation towards the policy proposal has been heard on the list. Best, Martin
While I speak only for myself, I think I dare say that your voice of reservation towards the policy proposal has been heard on the list.
aside from geza, a lot of old dogs have expressed similar reservations. geza has just had more persistence than the rest of us. randy
Hella Geza, On Wed, Oct 5, 2011 at 9:52 PM, Turchanyi Geza <turchanyi.geza@gmail.com> wrote:
How many IPv6 entries can be added if the total capacity of the line card is 0.5M IPv4 routing entry?
Are there no line cards with larger capacity in development? Will we still be limited to 0.5M when the problem (i think it is a long term problem) arises? Don't get me wrong, I know what your concerns are, and I think you have good reason for them. I just don't like fitting IPv6 development (if there still is one, sometimes we are just stuck) into routers, I would rather change the routers to cope with the "new" technology. I haven't seen much line cards holding DFZ in my life, since I used quagga and bird. Why is this such a big problem with those line cards? Is it _our_ problem or the _vendors_ one, once the table reaches 0.5M? Would you buy a line card that cannot handle your line? regards, danrl
On Thu, 6 Oct 2011, Dan Luedtke wrote:
Are there no line cards with larger capacity in development? Will we still be limited to 0.5M when the problem (i think it is a long term problem) arises?
There are very few platforms today with a 0.5M limit, buying them even a few years back, would be a mistake. The most popular platforms I would say have a 1M or more forwarding table limit, meaning they'll do ~750k IPv4 and 125k IP6 routes (IPv6 takes double space) or 500k IPv4 and 250 IPv6 routes, or any mix in between. There are platforms on the market that do twice this, and scalability numbers keep going up. I'd say the route ratios (routes in DFZ and number of routes handled by cutting edge platforms) and convergence times have been fairly constant in the last 10 years, even as IPv4 routes have gone from ~100-150k to 350k. There is plenty of equipment developed 10+ ago that still can handle the current number of DFZ routes. However, there is still a cost to this as equipment will have to be replaced due to their route memory not being enough, instead of other factors (forwarding speed for example). This is still a problem, it's still costing money, but I'd venture to guess it's not big enough amount to make sure someone will actually fix this. As long as we keep the current growth rate, it's not really a technical problem. It also means there won't be any improvement in convergence time, which actually IS a technical problem, but not one seen to be a big enough of a problem either, I guess. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hello Mikael, On Tue, Oct 4, 2011 at 9:51 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
On Tue, 4 Oct 2011, Turchanyi Geza wrote:
Let's clarify first: roughly how many router cards MUST be upgraded if the
typical 0,5M limit reached (counting twice en IPv6 enty).
In parallel, we should better understand the slow-down consequences as well.
While I agree with you, this is way too late, and people don't generally care about this cost (at least not officially). RIPE is disconnected from routing, and the routing subsystem is not something people generally care about in this policy wg (my opinion).
RIPE hands out addresses, they do not do routing.
Well, there was a routing-wg of RIPE...
So let's make the IPv6 PI policy the same as IPv4 (remove multihoming) and then we monitor growth. When it hits 100k IPv6 PI (or some other number) prefixes, let's review again.
NO.Address allocation should not follow "a la mode" trends. The limits of
the existing infrastrucure should not be forgotten. My dystopian view is that this won't be fixed but instead vendors will have
to create routers that can handle many million of routes in the next decades. This will cost a lot of money, but that might still be cheaper than trying to get smaller ISPs and enterprise to aquire and handle renumbering mechanisms that haven't even been developed yet.
I do not want to stop the development at all. BUT. let's first develop the new technology, test it, prove it, then we might enjoy the freedom created.
BUT doing the other way around will create just mess. Or even a collapse, within one or may be one and half year. Please think about this limit also.
-- Mikael Abrahamsson email: swmike@swm.pp.se
Thanks, Géza
RIPE hands out addresses, they do not do routing.
Well, there was a routing-wg of RIPE...
Was and is, and indeed perhaps some of the discussion on where the routing table for IPv4 and IPv6 may be in a decade is best suited for that list. I will, however, proffer a reminder that the RIPE NCC hands out addresses based on policies that the RIPE community decides. This discussion on 2011-02 is in 'last call,' which is supposed to mean that 'we as a community have reached consensus, are there any major show-stoppers we have missed?' Perhaps we can move the future of routing discussion over to the routing working group (although having an aim for the discussion would be useful) and leave the discussion on this list to either 'nothing new, carry on' or 'whoah! we've completely missed this before.' All the best, Rob
On Tue, Oct 4, 2011 at 9:51 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
RIPE is disconnected from routing, and the routing subsystem is not something people generally care about in this policy wg (my opinion).
RIPE hands out addresses, they do not do routing.
This is quite true. There's no minimum IPv4 PI assignment size, for example. Best, Martin
Mikael Abrahamsson wrote: We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes.
We have known that for 20 years; it was part of the very design of IPv6: small, aggregated DFZ. Unfortunately, nobody has been able to deliver it. Another undelivered feature is easy renumbering, which is why we are starting to see all kinds of IPv6 NAT. Time to wake up: Even IPv4 address shortage has not triggered IPv6 adoption; no PI and no NAT are small perks compared to address shortage.
So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution.
This is the wording I object. By writing this, you are saying that the quest for the Holy Grail has not stopped and implying that we will find it. Don't get me wrong: 10 years ago I wrote that, too. But now the game has changed: we do not have another 20 or 50 years to deploy IPv6. For the same reasons most have eliminated other protocols such as IPX, Appletalk, DECNET, etc in favor of IPv4, we do not have eternity before people start to fall back on IPv4-only networks, if IPv6 adoption remains at the current levels and growth rate. It's too late to talk about making IPv6 better. The only game left is the survival of IPv6, not dreams for 50 years from now.
We know it's bad, we still use it because there is no better way right now. That doesn't mean we should give up.
I'm saying that not only we should give up, but we must give up. Although they are not the main reason, never-ending changes in deployment strategies are one of the factors that slow down adoption. Time to finalize deployment scenario has come. By keeping the quest for the Holy Grail open, you send the wrong message out. The message you are sending out is that you are still looking for ways to slow distribution of IPv6 PI addresses, and this is one of the things that makes potential adopters run away from it and invest in CGNs instead.
It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much.
Denial to recognize the fact that organizations will always go for the easy way out is precisely where we collectively have failed. The grand scheme of doing what is right does not work in the real word. You are still in denial that the initial design objectives have not been met. Michel.
Hello Michel, What we learned in the past is that PI address disstribution does not scale - it provoques routing tables what we can not handle. This was the reason while CIDR and PA address allocation had benn introduced and even pushed in some extent. On Sat, Oct 1, 2011 at 4:32 AM, Michel Py < michel@arneill-py.sacramento.ca.us> wrote:
Mikael Abrahamsson wrote: We still need to in the long term. IPv6 PI, ie keeping state for all end-users in all DFZ routers on the Internet, does not scale with billions of routes.
We have known that for 20 years; it was part of the very design of IPv6: small, aggregated DFZ. Unfortunately, nobody has been able to deliver it.
Wrong. The IPv6 DFZ is small as an ISP has only 1-2 hugh IPv6 address block. IPv6 PI will destroy this structure, this is the danger.
Another undelivered feature is easy renumbering, which is why we are starting to see all kinds of IPv6 NAT.
NAT is used also for monitoring the traffic. IPv6 without NAT is delayed because many organisation wants to monitor the traffic (for company secret keeping, for example) and these companies have no tools at the moment (these tools are under development by operation system developer, wich will allows traffic monitoring at your computer(.
Time to wake up: Even IPv4 address shortage has not triggered IPv6 adoption; no PI and no NAT are small perks compared to address shortage.
Really time to wake up!
So yes, there is no solution right now, that doesn't mean IPv6 PI is any kind of long term solution.
IPv6 PI really not long term solution.
This is the wording I object. By writing this, you are saying that the quest for the Holy Grail has not stopped and implying that we will find it. Don't get me wrong: 10 years ago I wrote that, too. But now the game has changed: we do not have another 20 or 50 years to deploy IPv6.
For the same reasons most have eliminated other protocols such as IPX, Appletalk, DECNET, etc in favor of IPv4, we do not have eternity before people start to fall back on IPv4-only networks, if IPv6 adoption remains at the current levels and growth rate.
It's too late to talk about making IPv6 better. The only game left is the survival of IPv6, not dreams for 50 years from now.
Fully aggree, the the only game left is the survival of the IPv6. AND fast implementation by content providers (which is still the a week point, with a few exeptions and coordinated efforts of Goggle) AND fast provision by massive home network providers.
We know it's bad, we still use it because there is no better
way right now. That doesn't mean we should give up.
I'm saying that not only we should give up, but we must give up. Although they are not the main reason, never-ending changes in deployment strategies are one of the factors that slow down adoption. Time to finalize deployment scenario has come.
By keeping the quest for the Holy Grail open, you send the wrong message out. The message you are sending out is that you are still looking for ways to slow distribution of IPv6 PI addresses, and this is one of the things that makes potential adopters run away from it and invest in CGNs instead.
It's again tragedy of the commons. For the individual user, PI is always the easiest way out. For humanity/Internet as a whole in the long term, not so much.
Denial to recognize the fact that organizations will always go for the easy way out is precisely where we collectively have failed. The grand scheme of doing what is right does not work in the real word.
It must, sorry.
However, you are right that we are facing to the social aspects of the Internet transition. We know that the humanity must reduce the green-house effects by reducing CO2 production, we know thast fueling our cars should be drastically changed and we know that massive IPv6 deployment with smart routing table is a must.
You are still in denial that the initial design objectives have not been met.
Social problems are everywhere, including this mailing list. No surprise.
Michel.
Thanks, Géza
Gert and all, On Thu, Sep 29, 2011 at 8:56 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Sep 29, 2011 at 11:42:59AM -0700, Scott Leibrand wrote:
It's worth noting that a similar PI policy has been in place in the ARIN region for some time now, and has not resulted in any large increase in the IPv6 routing table.
Yes. I have watched the global table fairly closely for the last years, and indeed, the number of PI routes in the global IPv6 table is well under control so far (and the rate it's growing is also under control).
Slides up to May are in my RIPE62 IPv6 routing table report, but if it helps, I can go through the numbers and provide up-to-date graphs.
Sander's announcement also had the most recent numbers of PA-vs-PI routes in it.
Right. If the situation remain reasonable, then the educatedly guessed limit will never hit, and everybody will be happy. However, I think we should be prepared for the worst scenario as well.
Gert Doering -- just providing background data
Best, Géza
Hi Gert, On Thu, Sep 29, 2011 at 8:56 PM, Gert Doering <gert@space.net> wrote:
Hi,
On Thu, Sep 29, 2011 at 11:42:59AM -0700, Scott Leibrand wrote:
It's worth noting that a similar PI policy has been in place in the ARIN region for some time now, and has not resulted in any large increase in the IPv6 routing table.
Yes. I have watched the global table fairly closely for the last years, and indeed, the number of PI routes in the global IPv6 table is well under control so far (and the rate it's growing is also under control).
Slides up to May are in my RIPE62 IPv6 routing table report, but if it helps, I can go through the numbers and provide up-to-date graphs.
I was actually looking for you the other day on IRC... I saw a couple of /48's in DFZ coming not from PIv6, but allocated by LIR's (thus, announced with different origin than the /32 they came from), the other day. IIRC, your data captured these [ easier-than-PIv6 ] allocations as well. Is that right? It would be interesting to see graphs of these and over time, if possible, to try and detect and correlate changes with policy, somehow. Thanks, Regards, Martin
Hi, On Fri, Sep 30, 2011 at 05:43:37PM +0200, Martin Millnert wrote:
I was actually looking for you the other day on IRC... I saw a couple of /48's in DFZ coming not from PIv6, but allocated by LIR's (thus, announced with different origin than the /32 they came from), the other day. IIRC, your data captured these [ easier-than-PIv6 ] allocations as well. Is that right?
My scripts break down the numbers by raw size (so-many /48s, so-many /32s), which is where the numbers that Sander posted came from - so it's actually even less PIv6 than /48s out there, yes: http://www.space.net/~gert/RIPE/R62-v6-table/page24.html I have another script that breaks down the numbers by region and by category (PA/PI/IXP/...), but haven't run that one since May - the May numbers are here: http://www.space.net/~gert/RIPE/R62-v6-table/page26.html http://www.space.net/~gert/RIPE/R62-v6-table/page28.html the "more specifics from PA netblocks" show up in the "subnets" column of the "LIR" rows, and indeed, in May we had about 1800 PA deaggregates in the table, of about 5500 routes in total. I'll re-run these scripts some time next week, and post fully up-to-date numbers.
It would be interesting to see graphs of these and over time, if possible, to try and detect and correlate changes with policy, somehow.
In slide 26 you can get an idea on the effects of PI on the global table over time. That slide shows the majority of "non-PA" routes to be from the ARIN region (which is in line with them having the first IPv6 PI policy at all, and a fairly liberal with that), and they had reached ~700 "non-PA" routes in May (with ~1400 "PA" routes). You can't really see policy changes there, except for the "from now on, you can have PI!" kickoff - but what you can see is the effect of the RIR IPv6 marketing campaigns, notably APNIC in early 2010. Gert Doering -- with the IPv6 numbers hat on -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Geert, thanks! On Sun, Oct 2, 2011 at 7:51 PM, Gert Doering <gert@space.net> wrote:
It would be interesting to see graphs of these and over time, if possible, to try and detect and correlate changes with policy, somehow.
In slide 26 you can get an idea on the effects of PI on the global table over time. That slide shows the majority of "non-PA" routes to be from the ARIN region (which is in line with them having the first IPv6 PI policy at all, and a fairly liberal with that), and they had reached ~700 "non-PA" routes in May (with ~1400 "PA" routes).
You can't really see policy changes there, except for the "from now on, you can have PI!" kickoff - but what you can see is the effect of the RIR IPv6 marketing campaigns, notably APNIC in early 2010.
I was unclear. I meant, from now on and into the future. :) (ie, keep doing the stats.) Looking forward for your re-run. Thanks again, Regards, Martin
Hi, speaking to myself again... On Sun, Oct 02, 2011 at 07:51:23PM +0200, Gert Doering wrote:
On Fri, Sep 30, 2011 at 05:43:37PM +0200, Martin Millnert wrote:
I was actually looking for you the other day on IRC... I saw a couple of /48's in DFZ coming not from PIv6, but allocated by LIR's (thus, announced with different origin than the /32 they came from), the other day. IIRC, your data captured these [ easier-than-PIv6 ] allocations as well. Is that right? [..] I'll re-run these scripts some time next week, and post fully up-to-date numbers.
So here's the (to-be-) weekly updated numbers: http://www.space.net/~gert/RIPE/weekly/ http://www.space.net/~gert/RIPE/weekly/2011/43/ most of the material is "the slides that I always do", just with the most recent numbers - there is one image that's new, and that's breaking down the routing table by "LIR prefixes", "non-LIR prefixes" (=PI), and "more specifics of either category". The text has more explanation how the matching to categories is done. ... sending this, I see questions coming up "can we have this for 5-year ranges" - yes, can be done, but the apparatus isn't there yet. Stay tuned. Gert Doering -- IPv6 number geek -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On Fri, Sep 23, 2011 at 02:15:32PM +0200, Sander Steffann wrote:
We will ask the RIPE NCC to ask for extensive documentation in the IPv6 PI request form about why IPv6 PI space is requested instead of PA space.
This requirement, completely negates the intent of the policy change. While it benefits a small amount of applicants (non-multihomed PIv6), it adds an unreasonable administrative burden on every other PIv6 applicant. I thus withdraw my support for this change unless the "extensive documentation" requirement is removed. rgds, Sascha Luck
Hi Sasha,
I thus withdraw my support for this change unless the "extensive documentation" requirement is removed.
This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed. Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC. - Sander
This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed.
Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC.
I support the policy under the terms stated above. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
Hi,
Hi Sasha,
I thus withdraw my support for this change unless the "extensive documentation" requirement is removed.
This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed.
Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC.
while i certainly think that this idea was well intended (it actually makes some sense to me in general, but not in this context), i am happy to hear that we can go on with this one without any more discussion. Still supporting 2011-02 :-) -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hi Sander, On Fri, Sep 23, 2011 at 04:11:35PM +0200, Sander Steffann wrote:
This is not part of the policy but a suggestion to the RIPE NCC. It seemed useful information to have, but if people think it is not then we won't suggest this to the NCC. However, all of this is part of the implementation (which is up to the NCC) and not part of the policy. The policy hasn't changed.
This suggestion, if followed, would implicitly become policy without consensus from the PDP. I assume that is what Nick alludes to in his reply. IMO, that would be a dangerous precedent to set. Besides, the request form already contains the "why-pi" question. A requirement to "prove that you're worthy" would just lead to applicants concocting whatever story they think the IPRA will believe and be completely useless information.
Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC.
Without the requirement I do, of course, fully support the policy. cheers, Sascha
Hi Sasha,
Besides, the request form already contains the "why-pi" question.
So my suggestion was redundant anyway...
A requirement to "prove that you're worthy" would just lead to applicants concocting whatever story they think the IPRA will believe and be completely useless information.
I think you misunderstood me. I wanted a (maybe bit more extensive) why-pi question. The question would be for documentation purposes only. I don't *ever* want the NCC to add a question that actually influences the decision without that being approved through the full PDP! My apologies if I created that impression.
Considering that this well-intended suggestion to the NCC seems to have caused controversy and distract from the actual policy proposal we will not send the suggestion to the NCC.
Without the requirement I do, of course, fully support the policy.
Thank you expressing you opinion explicitly. That makes our lives as working group chairs so much easier! Sander
Hello working group, On Fri, Sep 23, 2011 at 2:15 PM, Sander Steffann <sander@steffann.nl> wrote:
The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space.
I support the policy change, even if (out of the blue for me) there is a additional burden of explaining my request for documentation. As I understood, explanations for PIv6 requests are to be documented by RIPE, but those explanations won't be a reason to reject requests if all other requirements are meet. I'd like to encourage everyone to make clear that this is optional. Nevertheless, this is not what was actually proposed, is it? regards, Dan -- danrl / Dan Luedtke http://www.danrl.de
Hi Dan,
On Fri, Sep 23, 2011 at 2:15 PM, Sander Steffann <sander@steffann.nl> wrote:
The intention of this is to be able to analyze the reasons for organizations to request PI space and to make requesters think twice when requesting PI space.
I support the policy change, even if (out of the blue for me) there is a additional burden of explaining my request for documentation. As I understood, explanations for PIv6 requests are to be documented by RIPE, but those explanations won't be a reason to reject requests if all other requirements are meet.
That is what I suggested, but...
I'd like to encourage everyone to make clear that this is optional.
Nevertheless, this is not what was actually proposed, is it?
... my suggestion caused confusion and comments, so I'm not suggesting it anymore :-) What is proposed is exactly what is described in http://www.ripe.net/ripe/policies/proposals/2011-02. The only thing we ask the NCC is to regularly report / provide statistics on the effects of this policy. Thanks, Sander
participants (25)
-
Arturo Servin -
bmanning＠vacation.karoshi.com -
Dan Luedtke -
Daniel Roesen -
Daniel Stolpe -
David Conrad -
David Monosov -
Erik Bais -
Gert Doering -
Havard Eidnes -
Jasper Jans -
Jörgen Eriksson -
Martin Millnert -
Michel Py -
Mikael Abrahamsson -
Nick Hilliard -
Peter Koch -
Randy Bush -
Rob Evans -
Sander Steffann -
Sascha Lenz -
Sascha Luck -
Scott Leibrand -
Turchanyi Geza -
Wilfried Woeber, UniVie/ACOnet