2011-02 New Draft Document Published (Removal of multihomed requirement for IPv6 PI)
Dear Colleagues, The draft document for the proposal described in 2011-02 has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2011-02 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2011-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 26 July. Regards Emilio Madaio Policy Development Officer RIPE NCC
On 28 June 2011 11:58, Emilio Madaio <emadaio@ripe.net> wrote:
You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2011-02
Okay I'll bite... "Although the Board is unconvinced that the chosen approach is the best possible solution for the described problem, the decision is of course deferred to the RIPE community." do they have another suggestion? J -- James Blessing 07989 039 476
<all hats off> This is a bit of a complicated hat situation. The RIPE NCC merely executes policy set by the community, so with my board hat on I find it difficult to go as far as even offering suggestions. While I do sympathise with the rationale behind the proposal, doing it this way strikes me as having an awful lot of (unintended?) side effects. I personally don't have a better suggestion to achieve resolution of the problem that this proposal aims to fix, but at the same time I'm unconvinced that everybody's who's been supporting the proposal has been doing so for the problem this policy aims to fix, and not one of its (again, unintended?) side effects. Remco van Mook On 28-06-11 13:35, "boggits" <boggits@gmail.com> wrote:
On 28 June 2011 11:58, Emilio Madaio <emadaio@ripe.net> wrote:
You can find the full proposal and the impact analysis at: http://www.ripe.net/ripe/policies/proposals/2011-02
Okay I'll bite...
"Although the Board is unconvinced that the chosen approach is the best possible solution for the described problem, the decision is of course deferred to the RIPE community."
do they have another suggestion?
J
--
James Blessing 07989 039 476
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
On 29 June 2011 14:25, Remco Van Mook <Remco.vanMook@eu.equinix.com> wrote:
This is a bit of a complicated hat situation. The RIPE NCC merely executes policy set by the community, so with my board hat on I find it difficult to go as far as even offering suggestions. While I do sympathise with the rationale behind the proposal, doing it this way strikes me as having an awful lot of (unintended?) side effects. I personally don't have a better suggestion to achieve resolution of the problem that this proposal aims to fix, but at the same time I'm unconvinced that everybody's who's been supporting the proposal has been doing so for the problem this policy aims to fix, and not one of its (again, unintended?) side effects.
Okay can we be clear about the reason for doing this before we continue with the discussion... A single IPv6 route will consume 4 x the space of a v4 route, whilst we are in the transition phase between v4 and v6 and having to allocate memory to both protocols adding potentially the equivalent to 70k to the routing table 'just because its easier' doesn't strike me as the most sensible thing to do in the world. Transition between 2 IPv6 suppliers (unlike IPv4) "shouldn't" require the same level of manual reconfiguration due IPv6's complexity crying out for some form of automation in its deployment in the first place. What I believe we should be looking at is education of the differences between v4 and v6 rather than changing policy. J -- James Blessing 07989 039 476
James, I know this has been discussed several times, but I can't stop myself... On Wed, 2011-06-29 at 14:50 +0100, James Blessing wrote:
A single IPv6 route will consume 4 x the space of a v4 route, whilst we are in the transition phase between v4 and v6 and having to allocate memory to both protocols adding potentially the equivalent to 70k to the routing table 'just because its easier' doesn't strike me as the most sensible thing to do in the world.
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming. So while routing table growth is a concern, PI policies are probably not a large factor.
Transition between 2 IPv6 suppliers (unlike IPv4) "shouldn't" require the same level of manual reconfiguration due IPv6's complexity crying out for some form of automation in its deployment in the first place. What I believe we should be looking at is education of the differences between v4 and v6 rather than changing policy.
My further understanding is that desire for PI is mostly for non-technical reasons. I don't think anything can make this motivation go away. Companies want it. -- Shane
On 29 June 2011 20:04, Shane Kerr <shane@time-travellers.org> wrote:
James,
I know this has been discussed several times, but I can't stop myself...
On Wed, 2011-06-29 at 14:50 +0100, James Blessing wrote:
A single IPv6 route will consume 4 x the space of a v4 route, whilst we are in the transition phase between v4 and v6 and having to allocate memory to both protocols adding potentially the equivalent to 70k to the routing table 'just because its easier' doesn't strike me as the most sensible thing to do in the world.
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming. So while routing table growth is a concern, PI policies are probably not a large factor.
True, but thats no excuse to pour fuel onto the fire.
Transition between 2 IPv6 suppliers (unlike IPv4) "shouldn't" require the same level of manual reconfiguration due IPv6's complexity crying out for some form of automation in its deployment in the first place. What I believe we should be looking at is education of the differences between v4 and v6 rather than changing policy.
My further understanding is that desire for PI is mostly for non-technical reasons. I don't think anything can make this motivation go away. Companies want it.
Okay but the point about the allocation of resources is that it should be done for technical rather than just pure business/political/paranoid reasons. Everyone is saying that IPv6 will 'last forever' but they said the same thing about oil too J -- James Blessing 07989 039 476
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming.
got cites? randy
On Thu, 30 Jun 2011, Randy Bush wrote:
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming.
got cites?
I think the routing table report "aggregation ratio" shows some of this. It might also be incompetence rather than intentional traffic engineering, that is fueling the growth. I know people who deaggregate their /19 into /24s and announce it to all their providers, because they have one per city and if that city is isolated, it still has connectivity even if their internal network is partitioned. If this should be called "traffic engineering" or not is debatable.
From the routing table report:
BGP routing table entries examined: 361681 Prefixes after maximum aggregation: 164222 I don't have figures showing these metrics over time, but I feel that de-aggregation ratio has increased, but not hugely. As long as announcing routes to the DFZ doesn't incur a cost per route, we're going to see the current situation continue, I guess. Luckily it seems core routing platforms keep up with the growth, even though platforms need to be upgraded prematurely due to them not being able to handle the current DFZ size. -- Mikael Abrahamsson email: swmike@swm.pp.se
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming. got cites? I think the routing table report "aggregation ratio" shows some of this.
where 'some' does not seem to include multihoming. so we can not compare.
I don't have figures showing these metrics over time, but I feel that de-aggregation ratio has increased, but not hugely.
my too subtle point is that someone should write a paper, with measurements, not feelings. randy
On 30/06/2011, at 5:30 PM, Randy Bush wrote:
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming. got cites? I think the routing table report "aggregation ratio" shows some of this.
where 'some' does not seem to include multihoming. so we can not compare.
I don't have figures showing these metrics over time, but I feel that de-aggregation ratio has increased, but not hugely.
my too subtle point is that someone should write a paper, with measurements, not feelings.
randy
Randy, On Thu, 2011-06-30 at 08:45 +0900, Randy Bush wrote:
My understanding is that routing table growth is largely fueled by traffic engineering rather than multihoming.
got cites?
As you know, I'm not a routing guy, so I tried to be careful with my language here. I'm neither an operator nor a researcher, so if I sound ignorant it is because I am. Having said that... One simple way to look at it is to consider how much PI space there is, versus routing table size. Looking at the latest copy of the RIPE Database, we find just under 29k PI assignments. I am told that the RIPE PI policy is the most lenient in the world, but if we assume that similar policies are in place throughout the world that still leaves less than 100k routes for all PI holders combined, compared to the 350k routes total. This does not tell us anything about the *growth* exactly, but it serves as a worst-case analysis: in the current Internet, most routes come from non-PI allocations. Further, a quick google for "routing table growth deaggregation" turns up the following paper: http://people.ee.ethz.ch/~wmuehlba/jsac-10.pdf It is a couple years old, and I don't know if the authors are trustworthy, but it seems nicely done. ;) The authors were looking for trends in changes in traffic engineering practices, and summarize: To sum up, given the differences in the two plots of Figure 7, we conclude that traffic engineering is a significant driver for address space deaggregation. However, based on the evolution since 2001, we cannot identify any sudden shift towards a more aggressive and widespread use of prefix deaggregation in order to achieve traffic engineering. This suggests that it is not an increasing demand for traffic engineering that inflates routing tables: rather, inflation is a consequence of the topological growth of the Internet combined with the lack of support for traffic engineering in the current routing system. Nevertheless, if we look at Fig. 3., we see that the percentage of prefixes from deaggregated routes has gone from like 17% in 2001 to 31% in 2008 - almost double. So while the amount of routes due to traffic engineering is not due to a fundamental change in practice, it seems probable to me that it is nevertheless the source of a lot of routing table growth. Regarding the implications on policy... we seem to have a situation where the people for and against increased IPv6 PI seem to think that the other side must prove their position somehow. These ideas are all based on potential future impact, and historically predictions about the future have been very difficult. Since we are talking about theories about future impact, we're kind of like economists: the only real way to test a theory is to implement it and see what happens. I will note that *not* changing the policy is also implementing a policy, so no matter what we do, we're running an experiment based on half-baked theories of how the Internet works. More research will certainly inform the discussion and possibly lead to better policies, but policies will never be based on perfect understanding. -- Shane
well, there you go!
It is a couple years old, and I don't know if the authors are trustworthy
some are, some are not. at ripe/rome, luca sent a bunch of us to a *really* horrible and disgusting restaurant. figure 7a is pretty telling. randy
Perhaps we should have an aggregation day and see if we can shift the tide by education & implementing better router configs. I dare to say that a lot of de-aggregation is due to bad configs, just look at the amount of leaking /28's-/32's and private AS's .. If people can't (don't) even filter intern internal subnets, no wonder you see /18's cut up into /24's or worse .. Erik Bais
Perhaps we should have an aggregation day and see if we can shift the tide by education & implementing better router configs.
I dare to say that a lot of de-aggregation is due to bad configs, just look at the amount of leaking /28's-/32's and private AS's ..
If people can't (don't) even filter intern internal subnets, no wonder you see /18's cut up into /24's or worse ..
ahhhh youth. i am soooo jealous of your optimism. not kidding. randy
-----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Thursday, June 30, 2011 3:19 PM To: Erik Bais
ahhhh youth. i am soooo jealous of your optimism. not kidding.
Thanks Randy, after my 39th b-day last week, that was just what I needed :) And yes, it might be optimistic to think we could turn the tide, however the numbers speak for themselves. And if we (as a community) could look at ourselves and improve what we advertize, it's a start. How many times did you check what you receive from certain peers and asked them to update their filtering, just because they are not looking at what they advertize ? I do this on a regular basis and often people send a reply back that they forgot, blame a colleague or what not, but the 'moral' of the story is that people have no clue and their routers just spit out whatever they like. Erik
Thanks Randy, after my 39th b-day last week, that was just what I needed :)
wanna trade?
How many times did you check what you receive from certain peers and asked them to update their filtering
and then depeered the worst
just because they are not looking at what they advertize ?
they are looking. it is intentional.
I do this on a regular basis and often people send a reply back that they forgot, blame a colleague or what not, but the 'moral' of the story is that people have no clue and their routers just spit out whatever they like.
often true at the smaller end. at medium/large there is a lot of intentional slicing to /24s, not for te but for hijack reduction. i am hoping that, over the years, rpki-based origin validation will remove some of the motivation for this. but that's my silly form of optimism. randy
On 6/30/11 10:29 AM, Randy Bush wrote:
It is a couple years old, and I don't know if the authors are trustworthy
some are, some are not. at ripe/rome, luca sent a bunch of us to a *really* horrible and disgusting restaurant.
ROTFL... I must be careful which restaurant I choose for you in November in Ljubljana then, as this seems pretty unforgiving :) cheers, /jan
On 30 June 2011 09:22, Shane Kerr <shane@time-travellers.org> wrote:
Regarding the implications on policy... we seem to have a situation where the people for and against increased IPv6 PI seem to think that the other side must prove their position somehow. These ideas are all based on potential future impact, and historically predictions about the future have been very difficult.
Since we are talking about theories about future impact, we're kind of like economists: the only real way to test a theory is to implement it and see what happens. I will note that *not* changing the policy is also implementing a policy, so no matter what we do, we're running an experiment based on half-baked theories of how the Internet works. More research will certainly inform the discussion and possibly lead to better policies, but policies will never be based on perfect understanding.
Okay let me put the case from this side, the number of 70k was based on quoted figure of current v4 PI assignments and the assumption (which I think is only logical) that each one of those assignments will want a v6 assignment at some point soon. This does not account for any growth in the desire for PI space that might appear based on people deciding that PI would a "better route" for their network design. The current global routing table for IPv6 is 5-6k (give or take) implementing this policy (as currently structured) would see that grow to around 20k (just with v4 -> v6 requirements) in a vert short space of time, now I don't know about your network but slow gradual growth is okay as you can budget for replacing and upgrading a normal cycle. A sudden spike like this is likely to cause two things to happen, first it'll trip over a raft of memory bugs that vendors haven't found yet because they didn't think the v6 table would grow so quickly and secondly it'll put those people with less available capital off deploying v6 as their hardware won't be up to scratch. I am happy to be convinced that I'm wrong and this won't be a problem *but* I'm still not convinced that this change is the best approach to solving "the problem" maybe the authors could pitch in with their problem statement so we can see what the actual problem is in the first place. J -- James Blessing 07989 039 476
Hi, [...]
The current global routing table for IPv6 is 5-6k (give or take) implementing this policy (as currently structured) would see that grow to around 20k (just with v4 -> v6 requirements) in a vert short space of time, now I don't know about your network but slow gradual growth is okay as you can budget for replacing and upgrading a normal cycle. A sudden spike like this is likely to cause two things to happen, first it'll trip over a raft of memory bugs that vendors haven't found yet because they didn't think the v6 table would grow so quickly and secondly it'll put those people with less available capital off deploying v6 as their hardware won't be up to scratch.
I am happy to be convinced that I'm wrong and this won't be a problem *but* I'm still not convinced that this change is the best approach to solving "the problem" maybe the authors could pitch in with their problem statement so we can see what the actual problem is in the first place.
why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up! So, i'm a little confused now why this is bad. I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-) And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes? I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion... -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hello, On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz <slz@baycix.de> wrote:
Hi,
[...]
why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up!
Not the IPv4 PI address space holders create the real problems...
So, i'm a little confused now why this is bad.
I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-)
And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes?
I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion...
We are concerned as well! However, the two tables share the same phisical memory!
-- Mit freundlichen Grüßen / Kind Regards
Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Géza
Hi,
Hello,
On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz <slz@baycix.de> wrote: Hi,
[...]
why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up!
Not the IPv4 PI address space holders create the real problems...
<?> I beg to differ, IPv4 is the problem, completely independent of "PI" and "PA" or anything we do with IPv6, by design.
So, i'm a little confused now why this is bad.
I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-)
And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes?
I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion...
We are concerned as well! However, the two tables share the same phisical memory!
And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that). Are you saying that we should not deploy IPv6? Guys, really, cope with the reality. Don't be like politicians and create FUD. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
On Fri, 1 Jul 2011, Sascha Lenz wrote:
And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that).
20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem. Right now the PI administration and implementation process is a barrier for entry, but if this changes then the amount of people who will want (and will get) PI might explode. Therefore the situation needs to be monitored, because having all core routers in the world keep track of every little entity who wants to redundantly connect to the Internet isn't going to scale. The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. -- Mikael Abrahamsson email: swmike@swm.pp.se
Are we really making an issue out of things that might not fit in a DFZ 30 years from now under the restrictions current - potentially already old(er) hardware has today? Who is really expecting to run the same boxes they do today 10 years from now - let alone 30 years? Jasper -----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Mikael Abrahamsson Sent: Friday, July 01, 2011 1:42 PM To: Sascha Lenz Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] Source of routing table growth On Fri, 1 Jul 2011, Sascha Lenz wrote:
And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that).
20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem. Right now the PI administration and implementation process is a barrier for entry, but if this changes then the amount of people who will want (and will get) PI might explode. Therefore the situation needs to be monitored, because having all core routers in the world keep track of every little entity who wants to redundantly connect to the Internet isn't going to scale. The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that. -- Mikael Abrahamsson email: swmike@swm.pp.se Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
Mikael Abrahamsson wrote:
20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem.
The problem is on prefix length over which backbone routers must take care of. 16M is not a problem if they are confined within /24. However, 5M scattered in /28 might be a problem.
The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that.
Yes, that is the real problem. Masataka Ohta
Hi, Am 01.07.2011 um 13:41 schrieb Mikael Abrahamsson:
On Fri, 1 Jul 2011, Sascha Lenz wrote:
And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that).
20k isn't a problem, 100k isn't really a problem, potentially 5M 30 years down the line might be a problem, 50M is most likely a problem.
You are in the IT business and you really think about 30+ years from now? Rather sounds like a science fiction author to me :-)
Right now the PI administration and implementation process is a barrier for entry, but if this changes then the amount of people who will want (and will get) PI might explode. Therefore the situation needs to be monitored, because having all core routers in the world keep track of every little entity who wants to redundantly connect to the Internet isn't going to scale.
This wasn't a real problem in the IPv4 world, i really doubt that is an immanent problem in the IPv6 world if the policies are identical; by design, most entities will have a single prefix (or per site worst case) and stay with that for most of their days. I'm not sure why there should be a higher IPv6 "PI" usage rate than for IPv4.
The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that.
I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
On Fri, 1 Jul 2011, Sascha Lenz wrote:
You are in the IT business and you really think about 30+ years from now? Rather sounds like a science fiction author to me :-)
Yes, I do. I consider that a responsible approach. IPv4 lasted ~30 years before it ran into serious problems, I want IPv6 to last a lot longer. I also want it to scale so everybody can use it.
This wasn't a real problem in the IPv4 world, i really doubt that is an immanent problem in the IPv6 world if the policies are identical; by design, most entities will have a single prefix (or per site worst case) and stay with that for most of their days.
Yes, but the problem is if everybody (or even 1%) in the world wants to multihome, then it doesn't scale.
I'm not sure why there should be a higher IPv6 "PI" usage rate than for IPv4.
Because more and more people (and companies) are adopting Internet usage and in 20-30 years time the demand for multihoming is most likely going to substantially higher than today. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi Sascha,
The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that.
I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed.
Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-) Thanks, Sander
Hi,
Hi Sascha,
The real solution is to have end systems handle session handover between multiple addresses it has, but there seems to be pitifully little traction for that.
I think we've been there (sounds a bit like SHIM to me), we'll see if that takes on. But i don't think such workarounds can replace BGP multihoming in all cases. But it can help to spare some people the hassle to deal with full BGP multihoming if don't really need to be in the DFZ, but just want some level of redundancy indeed.
Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-)
indeed! I am not scientist, i have no clue about how this problem can be solved, and since no one came up with anything better than SHIM the last decade, i guess BGP multihoming just cannot be replaced. Though, i've always explained to my clients that there are more easy and possibly cheaper options in most cases, and everyone else should inform their clients about alternatives, too. I have a poor opinion of those PI-shop-ISPs out there, they are doing something seriously wrong. But probably that's only a money issue which might be hopefully fixed with a new charging scheme (but forgive me if i am not convinced yet, dear NCC :-) ). But in the end, if the End-user WANTS and NEEDS independent resources, and can not live with anything else, i strongly disagree with deliberately preventing them from getting a slot in the routing table, or charging insane amounts of money for that. That's not the "internet spirit" i grew up with. ==> Work with your customers, most are easily convinced that bad BGP management can break more and cost more than more simple alternatives. Best we all can do. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Sander Steffann wrote:
Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-)
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs. Is it time to ressurect RFC2374? Masataka Ohta
Hi Masataka,
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
You don't make sense. We're not talking about ISPs here, we're talking about end users. And the IETF can define standards for that. - Sander
Sander Steffann wrote:
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
You don't make sense. We're not talking about ISPs here, we're talking about end users.
Considering that end users won't not directly suffer from nor complain about routing table explosions, but some clever ISPs may, we should be talking about ISPs, a collection of which is RIPE. Yes, ISPs through RIRs are the source of problems.
And the IETF can define standards for that.
The distance between IETF and end users is, mostly, infinite. Masataka Ohta
Masataka Ohta wrote: [...]
Yes, ISPs through RIRs are the source of problems.
And the IETF can define standards for that.
The distance between IETF and end users is, mostly, infinite.
Masataka Ohta
Some of the participants in this discussion seem to forget, always now and then, that the 'net and the ISPs are not existing for the benefit of themselves, but in order to provide service(s) to the users. Most of the time, the "infinitely distant users" are the primary soure of the money that keeps the 'net, the ISPs, the RIRs (and the scientists) in business. ;-) Wilfried.
On Sun, 3 Jul 2011, Wilfried Woeber, UniVie/ACOnet wrote:
Some of the participants in this discussion seem to forget, always now and then, that the 'net and the ISPs are not existing for the benefit of themselves, but in order to provide service(s) to the users. Most of the time, the "infinitely distant users" are the primary soure of the money that keeps the 'net, the ISPs, the RIRs (and the scientists) in business. ;-)
Correct, and most users do not have a PI and thus it's unfair to them if PI usage increase means their ISP has to swap equipment prematurely. -- Mikael Abrahamsson email: swmike@swm.pp.se
Dear Wilfried and Masataka. Both of you were right and both of you may be pleased by the new HOMENET working group of IETF, proposed recently by Jari Arko. (I proposed earlier a similar research initiative for FP7...) Best, Géza On Sun, Jul 3, 2011 at 8:12 PM, Wilfried Woeber, UniVie/ACOnet < Woeber@cc.univie.ac.at> wrote:
Masataka Ohta wrote: [...]
Yes, ISPs through RIRs are the source of problems.
And the IETF can define standards for that.
The distance between IETF and end users is, mostly, infinite.
Masataka Ohta
Some of the participants in this discussion seem to forget, always now and then, that the 'net and the ISPs are not existing for the benefit of themselves, but in order to provide service(s) to the users. Most of the time, the "infinitely distant users" are the primary soure of the money that keeps the 'net, the ISPs, the RIRs (and the scientists) in business. ;-)
Wilfried.
* Sander Steffann:
Hi Masataka,
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
You don't make sense. We're not talking about ISPs here, we're talking about end users. And the IETF can define standards for that.
The ISP vs end user distinction is very fuzzy. Even the RIPE policy documents don't use the terms consistently. And in most contexts, the term "ISP" includes companies mainly providing web and mail hosting services. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
The ISP vs end user distinction is very fuzzy. Even the RIPE policy documents don't use the terms consistently. And in most contexts, the term "ISP" includes companies mainly providing web and mail hosting services.
While I wrote "ISPs of RIPE and other RIRs", which should exclude end users, more general requirement is: only a small number of entities can have their own global routing table entries and if limited number of routing table entries are sold: only a very rich entities can have their own global routing table entries But, the first question is whether ISPs of RIPE can accept the requirement. If not, there is no point to ask other entities accept the requirement. Adrian Czapek wrote:
Who will be the one to define "very large" ?
It depends on how global routing table entries are obtained. For an example, see above. Political power may also be useful. Masataka Ohta
On 02/07/2011 08:35, Masataka Ohta wrote:
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
Why not put forward a proposal to the APWG along these lines then? Nick
W dniu 2011-07-02 12:25, Nick Hilliard pisze:
On 02/07/2011 08:35, Masataka Ohta wrote:
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
Why not put forward a proposal to the APWG along these lines then?
Who will be the one to define "very large" ? -- Adrian
On 7/2/11 9:35 AM, Masataka Ohta wrote:
Sander Steffann wrote:
Getting a good solution for this is _very_ important to limit routing table growth. Many people/organizations probably don't want the hassle of BGP if they can get more redundancy and less dependencies on a single ISP (easier renumbering will help too) in a simpler way. But this is IETF territory, not RIPE :-)
IETF can do nothing unless ISPs of RIPE and other RIRs accept the restriction that only very large ISPs can have their own global routing table entries and address spaces of other ISPs must be delegated from those of the very large ISPs.
RIPE is not a place to discuss this, as RIPE is all about resources allocation and policies around that, not how resources are used. IETF is not a place to discuss that, as if we understand what IETF stands for - that's engineering body that makes protocols and standards, not how resources are used. So we need new institution for that, let's call it "Internet Routing Police". Should I start filling in the registration papers for new not-for-profit institute with that name? :) Cheers, Jan Zorz
On Sun, Jul 03, 2011 at 08:44:08PM +0200, Jan Zorz @ go6.si wrote:
RIPE is not a place to discuss this, as RIPE is all about resources allocation and policies around that, not how resources are used.
RIPE has a long history of dealing with things outside of the resource allocation and policy matters. With the IPv6 equipment requirement document (RIPE-501) - authored partly by yourself - being the most "offtopic" one I'm aware of. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 7/3/11 10:01 PM, Daniel Roesen wrote:
On Sun, Jul 03, 2011 at 08:44:08PM +0200, Jan Zorz @ go6.si wrote:
RIPE is not a place to discuss this, as RIPE is all about resources allocation and policies around that, not how resources are used.
RIPE has a long history of dealing with things outside of the resource allocation and policy matters. With the IPv6 equipment requirement document (RIPE-501) - authored partly by yourself - being the most "offtopic" one I'm aware of.
Hi, I agree :) But there is difference between BCP and policy. If we can fix routing table growth with BCP, then let's try :) What I'm afraid here is that we need stronger means than BCP for this matter. Cheers, Jan
Hello, Yes, IPv4 only is a problem ;-)) Please, do not create more problem now! The limits of the content addressable memory on line card are problematic! Unfortunately the IPv4 address space trading will increase the memory size needed for IPv4 already. If you introduce IPv6 PI address space, who could stop to explode this space in the near future? Best, Géza On Fri, Jul 1, 2011 at 1:23 PM, Sascha Lenz <slz@baycix.de> wrote:
Hi,
Hello,
On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz <slz@baycix.de> wrote: Hi,
[...]
why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up!
Not the IPv4 PI address space holders create the real problems...
<?> I beg to differ, IPv4 is the problem, completely independent of "PI" and "PA" or anything we do with IPv6, by design.
So, i'm a little confused now why this is bad.
I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-)
And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes?
I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion...
We are concerned as well! However, the two tables share the same phisical memory!
And why do you have gear that got no problem with an exploding IPv4 table after exhaustion, but can't cope with 20k IPv6 prefixes? I still don't get that. Please, someone finally explain to me why 20k or even 100k IPv6 Prefixes in the DFZ is a problem, my lab says, even my 5year old Ciscos and Junipers have no problems with that right now. The default for an old Sup720 is 500k IPv4 + 250k IPv6 prefixes or so for example (IIRC, was some time ago i tested that).
Are you saying that we should not deploy IPv6?
Guys, really, cope with the reality. Don't be like politicians and create FUD.
-- Mit freundlichen Grüßen / Kind Regards
Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hi,
Hello,
Yes, IPv4 only is a problem ;-))
Please, do not create more problem now! The limits of the content addressable memory on line card are problematic!
Unfortunately the IPv4 address space trading will increase the memory size needed for IPv4 already.
If you introduce IPv6 PI address space, who could stop to explode this space in the near future?
i'm officially out of arguments now. We already have IPv6 PI, that's not gonna change. We're only about to level the IPv4 and IPv6 PI policies. You can either have people stay with IPv4 for a longer period as necessary, creating a faster and faster IPv4 table growth because they stick with this old legacy protocol, buying (and announcing) smaller and smaller IPv4 prefixes because they cannot migrate to IPv6 due to the policies being different, or you can allow the same rules for both worlds, give everyone their (most likely only ever) IPv6 prefix and have the v4 table stop growing earlier because people migrate faster. I think it's clear what we should chose. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
On Jul 1, 2011, at 12:46 PM, Turchanyi Geza wrote:
Hello,
On Thu, Jun 30, 2011 at 11:04 AM, Sascha Lenz <slz@baycix.de> wrote: Hi,
[...]
why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up!
Not the IPv4 PI address space holders create the real problems...
So, i'm a little confused now why this is bad.
I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-)
And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes?
I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion...
We are concerned as well! However, the two tables share the same phisical memory!
Not to mention all the routes in the various VRFs - a large L3VPN deployment can surpass a single instance of the global v4 and v6 table combined... ...all a pittance of course compared to the state in a big CGN. - Mark
-- Mit freundlichen Grüßen / Kind Regards
Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Géza
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Shane Kerr wrote on 29/06/2011 21:04: [...]
My further understanding is that desire for PI is mostly for non-technical reasons. I don't think anything can make this motivation go away. Companies want it.
PI also has non-technical implications. In terms of the maintenance fee, accountability, etc. So far it has been a loophole letting you to get a chunk bigger that the minimum allocation size for a fixed Eur50 (+your friendly LIR overhead) per year. But hopefully this can be fixed outside this policy proposal. Andrei -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk4NtL0ACgkQljz5tZmtij/78ACglSCfJWLmlw+BXCSmnrLe7ElS QW0AmJsPEEld+8H1iM5Zo6rzIrDMZLw= =QzBb -----END PGP SIGNATURE-----
Hi, On Fri, Jul 01, 2011 at 01:51:25PM +0200, Andrei Robachevsky wrote:
PI also has non-technical implications. In terms of the maintenance fee, accountability, etc. So far it has been a loophole letting you to get a chunk bigger that the minimum allocation size for a fixed Eur50 (+your friendly LIR overhead) per year.
But hopefully this can be fixed outside this policy proposal.
These are contractual and payment matters, and are outside the scope of this particular policy proposal. Nevertheless, it's being worked on - Jochem de Ruig (NCC finances) and the NCC board are working on a new charging scheme that should solve some of *these* problems. Gert Doering -- APWG chair -- did you enable 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 28 Jun 2011, at 12:35, boggits wrote:
Okay I'll bite...
"Although the Board is unconvinced that the chosen approach is the best possible solution for the described problem, the decision is of course deferred to the RIPE community."
do they have another suggestion?
James, the NCC Board does not make policy. For address management policy-making, it's this WG which does that. [The name of the WG is a big hint... :-)] I hoped everyone knew that. The Board's job is to oversee the NCC on behalf of its members but not get involved in operational matters. Besides, by the time a policy proposal gets in front of the Board (impact assessment, etc), the PDP is in the end- game and the proposal is pretty much the settled will of the RIPE community. In this case, the Board seems to be saying it doesn't think the proposed solution is ideal but will go along with what the RIPE community decides. I'm sure that if the Board felt that decision was not in the best interests of the NCC, they wouldn't keep quiet about the matter.
Hello Jim, Your comments are 100% valid, however one of your conclusion might be misleading. James, the NCC Board does not make policy. For address management
policy-making, it's this WG which does that. [The name of the WG is a big hint... :-)] I hoped everyone knew that. The Board's job is to oversee the NCC on behalf of its members but not get involved in operational matters. Besides, by the time a policy proposal gets in front of the Board (impact assessment, etc), the PDP is in the end-game and the proposal is pretty much the settled will of the RIPE community.
This is 100% valid.
In this case, the Board seems to be saying it doesn't think the proposed solution is ideal but will go along with what the RIPE community decides.
What else the Board could do?
I'm sure that if the Board felt that decision was not in the best interests of the NCC, they wouldn't keep quiet about the matter.
??? Best, Géza
On 30 Jun 2011, at 07:43, Turchanyi Geza wrote:
Your comments are 100% valid, however one of your conclusion might be misleading.
Only one? :-)
In this case, the Board seems to be saying it doesn't think the proposed solution is ideal but will go along with what the RIPE community decides.
What else the Board could do?
Depends. Is your question what can the Board do about this specific policy proposal or in a wider (theoretical?) context? Though my answer's still the same: it depends.
I'm sure that if the Board felt that decision was not in the best interests of the NCC, they wouldn't keep quiet about the matter.
???
We had this issue a few years ago over the proposal that required all PI holders to have a contract with the NCC. Which was before the current PDP had been finalised IIRC. The policy had reached consensus in the WG and it was then a simple matter of implementation. Until the Board and management realised what that entailed: hiring a small army of people to handle all the paperwork for thousands of PI holders. The Board decided this was a Bad Idea and asked the WG to reconsider. There is this ugly little gap in our policy making. The community which makes policy (RIPE) is not necessarily the same as the people who pay for that policy to be implemented (the NCC membership). The Board has to straddle that gap somehow. OTOH, it can't "make policy" or get involved in operational matters. On the other the Board has the usual responsibilities to look after the interests of the organisation (the NCC) and its members.
Hi,
We had this issue a few years ago over the proposal that required all PI holders to have a contract with the NCC. Which was before the current PDP had been finalised IIRC. The policy had reached consensus in the WG and it was then a simple matter of implementation. Until the Board and management realised what that entailed: hiring a small army of people to handle all the paperwork for thousands of PI holders. The Board decided this was a Bad Idea and asked the WG to reconsider.
Just for the record: we had the PDP already at that point in time and the objection was raised during last call. At no point in time has the board asked the working group to reconsider a policy that had already reached full consensus. The members of the board are also members of this community of course, so they can object to a policy in the same way everybody can...
There is this ugly little gap in our policy making. The community which makes policy (RIPE) is not necessarily the same as the people who pay for that policy to be implemented (the NCC membership). The Board has to straddle that gap somehow. OTOH, it can't "make policy" or get involved in operational matters. On the other the Board has the usual responsibilities to look after the interests of the organisation (the NCC) and its members.
At some point we refined the PDP to include an impact analysis by the RIPE NCC. Communication between the board and the WG and WG chairs has improved a lot as well. So I feel confident that any potential problems in this area will be openly discussed. Thanks, Sander
Hello Sander, Many thanks for your clarifications. However, I still think that the concept of implementing IPv6 PI address space never reached a full concensensus. Not even a rough one. We might run out of the routing tables before that IPv4 -> IPv6 transition goes above 80% -- this is a real danger! Let's accelarate the transition and come back to this issue whan it is almost complete! Thanks, Géza On Thu, Jun 30, 2011 at 11:04 PM, Sander Steffann <sander@steffann.nl>wrote:
Hi,
We had this issue a few years ago over the proposal that required all PI holders to have a contract with the NCC. Which was before the current PDP had been finalised IIRC. The policy had reached consensus in the WG and it was then a simple matter of implementation. Until the Board and management realised what that entailed: hiring a small army of people to handle all the paperwork for thousands of PI holders. The Board decided this was a Bad Idea and asked the WG to reconsider.
Just for the record: we had the PDP already at that point in time and the objection was raised during last call. At no point in time has the board asked the working group to reconsider a policy that had already reached full consensus. The members of the board are also members of this community of course, so they can object to a policy in the same way everybody can...
There is this ugly little gap in our policy making. The community which makes policy (RIPE) is not necessarily the same as the people who pay for that policy to be implemented (the NCC membership). The Board has to straddle that gap somehow. OTOH, it can't "make policy" or get involved in operational matters. On the other the Board has the usual responsibilities to look after the interests of the organisation (the NCC) and its members.
At some point we refined the PDP to include an impact analysis by the RIPE NCC. Communication between the board and the WG and WG chairs has improved a lot as well. So I feel confident that any potential problems in this area will be openly discussed.
Thanks, Sander
On Fri, 1 Jul 2011, Turchanyi Geza wrote:
However, I still think that the concept of implementing IPv6 PI address space never reached a full concensensus. Not even a rough one.
Even though I oppose easy IPv6 PI, I'd still say I was in enough majority to warrant claim of at least rough consensus.
We might run out of the routing tables before that IPv4 -> IPv6 transition goes above 80% -- this is a real danger!
We're not going to run out, there is no such thing. There is only pain level to rise, it's not going to stop working. I'm sure there are vendors who'd happily sell you devices in a few years that'll do 10M routes in FIB if they thought there was market demand. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hello, On Fri, Jul 1, 2011 at 12:14 PM, Mikael Abrahamsson <swmike@swm.pp.se>wrote: We're not going to run out, there is no such thing. There is only pain level
to rise, it's not going to stop working. I'm sure there are vendors who'd happily sell you devices in a few years that'll do 10M routes in FIB if they thought there was market demand.
Then ALL the routers in the backbone MUST be changed... is this a real alternative? Just for a bad decision? What about speed of convergence of there will be so many routes? Handling the limits of routes allowed today in first class backbone needs already long time, is n't it? Thanks, Géza
Hi,
On Fri, Jul 1, 2011 at 12:14 PM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
We're not going to run out, there is no such thing. There is only pain level to rise, it's not going to stop working. I'm sure there are vendors who'd happily sell you devices in a few years that'll do 10M routes in FIB if they thought there was market demand.
Then ALL the routers in the backbone MUST be changed... is this a real alternative?
Yes, all hardware will have to be replaced with new ones eventually for upgrades. That's just natural. I had to replace all the c3640s in my core 10years ago, too. And i will have to replace my current gear sooner or later. What's the big deal?
Just for a bad decision?
No, it's a bad decision to use old gear for longer than their supposed lifetime. Probably you should check your business plan if you can't keep up with upgrading your gear, especially if you're running a network oriented business.
What about speed of convergence of there will be so many routes?
Handling the limits of routes allowed today in first class backbone needs already long time, is n't it?
Do you have any evidence about this? Would love to read about the actual numbers. (That's not a rhetorical question, i really have no clue if there's a problem, i don't see any in the networks i manage, it never came up, but that doesn't mean there isn't one.) -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hi,
Do you have any evidence about this? Would love to read about the actual numbers. (That's not a rhetorical question, i really have no clue if there's a problem, i don't see any in the networks i manage, it never came up, but that doesn't mean there isn't one.)
This is not only related to the number of prefixes but also to the frequency with which the announcements of those prefixes are updated. IIRC there was something like the 20/80 rule here, in that 20% of the prefixes cause 80% of the updates. If we look at PI prefixes: I suspect most of those updates are for TE, and because a PI /48 is difficult to split into multiple smaller announcements I suspect the PI prefixes will belong to the 80% group that only cause 20% of the updates. This is just guess-work though. If someone can point me to decent research on this I would really appreciate it! Sander
This is not only related to the number of prefixes but also to the frequency with which the announcements of those prefixes are updated. IIRC there was something like the 20/80 rule here, in that 20% of the prefixes cause 80% of the updates.
<another troll> would be interesting if someone had actually measured this :) Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush, and Keyur Patel, Route Flap Damping Made Usable, in PAM 2011, March 2011. randy
This is not only related to the number of prefixes but also to the frequency with which the announcements of those prefixes are updated. IIRC there was something like the 20/80 rule here, in that 20% of the prefixes cause 80% of the updates.
<another troll> would be interesting if someone had actually measured this :)
Cristel Pelsser, Olaf Maennel, Pradosh Mohapatra, Randy Bush, and Keyur Patel, Route Flap Damping Made Usable, in PAM 2011, March 2011.
Thanks, Sander
On Fri, 1 Jul 2011, Sascha Lenz wrote:
I had to replace all the c3640s in my core 10years ago, too. And i will have to replace my current gear sooner or later. What's the big deal?
The big deal is that this gear might have a few more years in them for forwarding purposes, but they now have to be changed due to FIB size reason solely. -- Mikael Abrahamsson email: swmike@swm.pp.se
Hi, Am 28.06.2011 um 12:58 schrieb Emilio Madaio:
Dear Colleagues,
The draft document for the proposal described in 2011-02 has been published. The impact analysis that was conducted for this proposal has also been published.
You can find the full proposal and the impact analysis at:
http://www.ripe.net/ripe/policies/proposals/2011-02
and the draft document at:
http://www.ripe.net/ripe/policies/proposals/2011-02/draft
We encourage you to read the draft document text and send any comments to address-policy-wg@ripe.net before 26 July.
for now, i support this proposal for the reasons mentioned in all those threads we had before about the situation. But just for the record: i don't think it's "a good thing", but i do see the problems with the current situation. Fortunately we can and should closely monitor the outcome over the next years and rethink any policy again then if necessary. It's a bitch, but we know we can retroactively change policies, see the damned 2007-01 thing! :-) -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Fortunately we can and should closely monitor the outcome over the next years and rethink any policy again then if necessary. It's a bitch, but we know we can retroactively change policies, see the damned 2007-01 thing! :-)
Agreed, I support the proposal even though I'm uncomfortable with the possible outcomes, would like to see close monitoring of the situation. Dave. - -- David Freedman Group Network Engineering david.freedman@uk.clara.net Tel +44 (0) 20 7685 8000 Claranet Group 21 Southampton Row London - WC1B 5HA - UK http://www.claranet.com Company Registration: 3152737 - Place of registration: England All the information contained within this electronic message from Claranet Ltd is covered by the disclaimer at http://www.claranet.co.uk/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4LKckACgkQtFWeqpgEZrK0uQCfe76rn71iajRlYE5o6Zswk0QH OOkAoIK3TLuxqZqeW0bqdgsRUo5wE58J =AcVE -----END PGP SIGNATURE-----
Dear address-policy-wg, On 06/28/2011 12:58 PM, Emilio Madaio wrote:
Dear Colleagues,
The draft document for the proposal described in 2011-02 has been published. The impact analysis that was conducted for this proposal has also been published.
I would like to express my support for this proposal. Furthermore, I find the section 'E. RIPE NCC Executive Board' to be somewhat in bad taste; not only is it not the community's province to convince the RIPE NCC board of the merit of its ideas, the section also lacks any concrete facts, operational burden estimates or specific concerns and instead appears to do little more than attempt to tilt the opinion of the undecided against this proposal. -- Respectfully yours, David Monosov
On 07/07/2011 23:35, David Monosov wrote:
Furthermore, I find the section 'E. RIPE NCC Executive Board' to be somewhat in bad taste; not only is it not the community's province to convince the RIPE NCC board of the merit of its ideas, the section also lacks any concrete facts, operational burden estimates or specific concerns and instead appears to do little more than attempt to tilt the opinion of the undecided against this proposal.
The RIPE NCC board has a duty to remain in touch with the proposals currently being considered by the RIPE community, mainly to ensure that such proposals, if they are accepted by the community, do not raise unacceptable risks to the operations, financial and otherwise, of the RIPE NCC. In that sense the community *does* have to convince the RIPE NCC board of the merits of its ideas as the board has an ultimate responsibility (under law) to ensure that the RIPE NCC operates in a fiscally sensible manner. It also has a responsibility to its members which, although they have an extensive overlap with the RIPE community, are not the the same thing. In the RIPE region, the NCC Board operates with an extremely light touch. In other regions policy has to be signed off by the board as a final stage of acceptance and they can veto what they consider to be unacceptable policy. This does not happen in this region. Instead the board remains au fait with policy development and feeds their comments into the RIPE NCC evaluation of the policy. That is what you are seeing here, no more and no less. It is precisely because of this light touch that we have limited our comments to the fact that we feel some unease about the policy but feel that it is not our place to comment further but that we have confidence that the community will do the right thing. Further comments would be done as individuals, as usual. The community in general understands this, I believe. Best regards Nigel Titley Chairman of the RIPE NCC Board
Dear address-policy-wg, Nigel, On 07/08/2011 03:11 PM, Nigel Titley wrote:
That is what you are seeing here, no more and no less. It is precisely because of this light touch that we have limited our comments to the fact that we feel some unease about the policy but feel that it is not our place to comment further but that we have confidence that the community will do the right thing. Further comments would be done as individuals, as usual.
This is also precisely why I find this particular comment unnecessary and confusing, especially to members of the community which are not involved in the entire scope of discussion on the mailing lists, and instead evaluate policy proposals and their impact on their networks at 'face value' based on the content of the proposals themselves. If the board has specific operational or fiscal concerns, or even a formal board opinion, it would be a disservice to the policy process *not* to include them for consideration by the community. However, the board is highly regarded and respected by the community, which is exactly why I find a generic "we are not feeling it" remark to be inappropriate, and feel it should have instead been omitted completely in favor of individual comments on the mailing list, or included as a more specific and concrete set of concerns providing a constructive contribution to the community's ability to evaluate the impact of the proposal. -- Respectfully yours, David Monosov
On 08/07/2011 16:15, David Monosov wrote:
This is also precisely why I find this particular comment unnecessary and confusing, especially to members of the community which are not involved in the entire scope of discussion on the mailing lists, and instead evaluate policy proposals and their impact on their networks at 'face value' based on the content of the proposals themselves.
If the board has specific operational or fiscal concerns, or even a formal board opinion, it would be a disservice to the policy process *not* to include them for consideration by the community.
However, the board is highly regarded and respected by the community, which is exactly why I find a generic "we are not feeling it" remark to be inappropriate, and feel it should have instead been omitted completely in favor of individual comments on the mailing list, or included as a more specific and concrete set of concerns providing a constructive contribution to the community's ability to evaluate the impact of the proposal.
OK, with my personal hat on and not speaking for the board in any sense. 1. As far as I can see there are no fiscal issues here apart from the usual issue of more PI's meaning more NCC work meaning more staff (potentially) and hence more costs. 2. Speaking as an engineer, if you are too small to want PA space then you are small enough to renumber if you move provider. It's not really an issue these days (at least compared with the old days when /etc/hosts had to be updated on every machine in your network). And consuming a fib slot just to save yourself a bit of pain should you want to move provider strikes me as selfish. However, I'm an official old fart, and am probably harking back to an internet that no longer exists. I leave it up to the community to decide whether this is a constructive contribution or not. Nigel PS And thanks, David, for your very kind comments on the board.
Nigel, thanks for your words, espacially for your point 2. However, your point 1 should be refined
1. As far as I can see there are no fiscal issues here apart from the usual issue of more PI's meaning more NCC work meaning more staff (potentially) and hence more costs.
The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows. A total upgrade beed a couple of billon dollars. Unfortunately even if this many could be spent, the slow down provoked by the bigger table size could not be avoided. Therefore if we want to avoid total collaps or total up-grade and slow down in the very near future then all the FIBs grows should be minimised. Any proposal that might provoke a sudden grows of the FIBs should be postponed until the technology would evolve enough and allow to handle fast enough tha definitely larger FIBs.
2. Speaking as an engineer, if you are too small to want PA space then you are small enough to renumber if you move provider. It's not really an issue these days (at least compared with the old days when /etc/hosts had to be updated on every machine in your network). And consuming a fib slot just to save yourself a bit of pain should you want to move provider strikes me as selfish.
However, I'm an official old fart, and am probably harking back to an internet that no longer exists. I leave it up to the community to decide whether this is a constructive contribution or not.
Nigel
PS And thanks, David, for your very kind comments on the board.
Best, Géza
Hi, Am 09.07.2011 um 09:30 schrieb Turchanyi Geza:
Nigel,
thanks for your words, espacially for your point 2.
However, your point 1 should be refined
1. As far as I can see there are no fiscal issues here apart from the usual issue of more PI's meaning more NCC work meaning more staff (potentially) and hence more costs.
The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows.
A total upgrade beed a couple of billon dollars. Unfortunately even if this many could be spent, the slow down provoked by the bigger table size could not be avoided.
Therefore if we want to avoid total collaps or total up-grade and slow down in the very near future then all the FIBs grows should be minimised.
Any proposal that might provoke a sudden grows of the FIBs should be postponed until the technology would evolve enough and allow to handle fast enough tha definitely larger FIBs.
you still haven't provided any reasons why there should be a sudden spike and evidence suggesting that there will be. Why are you insisting on this? What is your secret agenda? Do you have any information you're not sharing? Again, and i just also repeat myself now, because mindless repetition seems to be cool in this discussion: - There already IS IPv6 PI in every RIR Region, i think you're barking up the wrong tree, we're not discussing the introduction of IPv6 PI here, you're some years late - It's highly unlikely that there will be more IPv6 PI Prefixes than IPv4 PI Prefixes any time soon in ANY way, that's BY DESIGN of IPv6 ("one prefix per entity" - usually). If your routers cannot handle that, you're doing something seriously wrong, or you have a wrong idea about the whole concept - It's highly likely that the IPv4 table WILL grow faster if PI-shops aren't able to use IPv6 without multihoming because they will literally buy smaller and smaller IPv4 prefixes and announce them to stay in business when they grow, so instead of one IPv6 PI Prefix you will provoke 10 IPv4 PI Prefixes in some cases - because THERE ALREADY IS NO MULTIHOMING REQUIREMENT for IPv4 PI If you want to do something about that, provide a counter-proposal retroactively introducing a multi-homeing requirement on IPv4 PI please and see what will happen. If it goes through and is accepted, we have the same policy for IPv4 and IPv6 PI again, and i'm also happy :-) </sarcasm> - It's almost completely independent of this proposal as long as HE does provide free IPv6 BGP Upstream tunnels :-) So why opposing this proposal at all if it does mean nothing for clueful people who just use a HE.net Tunnel as 2nd Peer and be happy to comply with the current policy? (okok, some might not want to do BGP themselves and pay for an AS# and so on, i admit this last one is rather a fun argument :-) But it makes a point that this proposal will have almost no impact if you look closer) All this proposal does is ease up IPv6 deployment for some entities who - for whatever stupid reason - rely on PI addresses without being multi-homed themselves. And THAT is what the majority should want, more IPv6, soon. Really, i still don't get it. Especially since the only problem here is the difference in IPv4 and IPv6 policies. It's more or less a transition problem for now. Why all the fuss NOW about such a simple policy change. This all was discussed years ago during the fight over IPv6 PI introduction. Now, did the world end with IPv6 PI? No. Will the world end with IPv6 PI? Probably, but i will have bought new routers long before that happens anyways. Is there more IPv6 deployment now? Yes (see number of PI assignments). I really like the outcome. -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
Hí Sascha, On Sat, Jul 9, 2011 at 10:14 AM, Sascha Lenz <slz@baycix.de> wrote:
you still haven't provided any reasons why there should be a sudden spike and evidence suggesting that there will be. Why are you insisting on this? What is your secret agenda? Do you have any information you're not sharing?
I think you should look into tho other end of the binoculars. If you propose something, you shold be able to think about the consequences. What might happen in two months, in one year, in 3 years and in ten years. This is your duty! The problem is that some people think that they can make policy proposals without thinking the technical and financial consequences. I you can prove that increasing the size of the routing table would not cause neither slow down nor extra cost then I will carefully listen to your arguments, as you definitely might invented something fundamentally new. However, have you read the paper mentionned by Randy Bush? Best, Géza
Hi,
you still haven't provided any reasons why there should be a sudden spike and evidence suggesting that there will be. Why are you insisting on this? What is your secret agenda? Do you have any information you're not sharing?
I think you should look into tho other end of the binoculars.
If you propose something, you shold be able to think about the consequences. What might happen in two months, in one year, in 3 years and in ten years.
This is your duty!
The problem is that some people think that they can make policy proposals without thinking the technical and financial consequences.
You still just repeat your point, without actually giving any argument or counter-argument to my explanations why i don't think your point is valid and why i think we need the policy change to ensure IPv6 adoption going more smoothly and faster. (Actually, this is a long-term view on the problem, i gave the argument why restricting IPv6 access might have an even more expensive impact on the (IPv4-)DFZ, read again). As long as you're not able to actually discuss anything, the best word for what i think you're doing is "lobbying", probably because you're company told you to or something. I have no idea why else you would stick to your point without being able to support it. :-(
I you can prove that increasing the size of the routing table would not cause neither slow down nor extra cost then I will carefully listen to your arguments, as you definitely might invented something fundamentally new.
Do you even know what you're talking about? Did you even read my arguments i gave at least twice? Does your company even have some business plan? The routing tables will grow, always, they always have. Plan for it. Everyone else does. This is nothing new. It's absolutely MAD that you think routing tables won't grow if you oppose this small policy change with no real impact whatsoever. PLEASE, write up your own proposal about what you would do in the big picture to slow routing table growth and see what happens. The PDP is open to anyone! And don't forget to do that in the other RIR regions, too!
However, have you read the paper mentionned by Randy Bush?
Yes, nice paper about route flap dampening. Exactly what i was asking for. As so often, good work Randy et. al.! Now, where does it say anything about the IPv6 routing table growth? Might have missed that page, i read it some days ago, can you give me the page number? Thanks. Or are you talking about another paper? -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect
ok children. enough.
Hi, On Sat, Jul 09, 2011 at 08:50:55PM +0900, Randy Bush wrote:
ok children. enough.
Indeed. Please bring the discussion somewhat back into focus. The proposal on the table does not introduce IPv6 PI, so this is not the question we need to discuss. The proposal at hand will neither help nor harm the IPv4 routing table, so this is also *not* the question to discuss. What we do need to make up our collective minds is: - do we want to see IPv6 deployed? (some of the comments can be read as "let's not deploy IPv6, because the IPv4 routing table is already too large!" - and I'm not convinced that this line of reasoning is conclusive) - do we think that the group of networks that would get IPv6 PI under the changed policy, but can't get IPv6 PI now is... a) large enough that it makes a difference regarding IPv6 deployment? b) small enough to avoid exploding the routing table? As for "b)", the numbers given by Alex Le Heux set a certain upper boundary for the number of IPv6 PI prefixes to expect - if every user of an IPv4 PI routing table slot today (in the RIPE region) will get an IPv6 PI block, we're "in the 10.000s" of routes, but not "in the millions". So we have some numbers. What we don't have right now is the number of IPv4 PI routes that are single-homed vs. IPv4 PI routes that are multihomed ("in a way that it can be seen from the vantage points used"). Maybe the RIPE NCC can help with some more numbers here. I purposely stay *out* of the discussion "why do people want IPv6 PI?" - if there are good reasons for IPv6 PI for single-homed networks, I think this is something the proposer should try to convince the WG of, but not the WG chairs. Gert Doering, APWG chair -- did you enable 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
* Turchanyi Geza:
The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows.
The RIPE NCC is not an Internet service provider, so this aspect is not relevant to RIPE NCC operations, and it does not justify interference from the board. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
The RIPE NCC is not an Internet service provider, so this aspect is not relevant to RIPE NCC operations, and it does not justify interference from the board. The board neither made this point, nor did they interfere. They expressed some personal disquiet about the proposal which in this case was leaked out through the RIPE NCC impact analysis (it normally doesn't get leaked and I'll make sure it doesn't again if this is the sort of
On 11/07/2011 08:53, Florian Weimer wrote: trouble it causes) Nigel
Hello Florian, On Mon, Jul 11, 2011 at 9:53 AM, Florian Weimer <fweimer@bfk.de> wrote:
* Turchanyi Geza:
The potential cost of applying more staff at the RIRs like RIPE NCC is just one issue. The more important issue is that all the line cards of the core routers should be replaced if we can not limit the grows of the forwarding tables (FIB)s. AND IPv4 address space trading allready might create problems concerning the grows.
The RIPE NCC is not an Internet service provider, so this aspect is not relevant to RIPE NCC operations, and it does not justify interference from the board.
When I started to work for the Internet development in 1991 it was a slogan what caught me:
Think globally, act locally! Whatever hat I would wear I would like to see a little bit longer and wider than the hat would suggest. Best, Géza
participants (28)
-
Adrian Czapek -
Andrei Robachevsky -
boggits -
Daniel Roesen -
David Freedman -
David Monosov -
Emilio Madaio -
Erik Bais -
Erik Bais
-
Florian Weimer -
George Michaelson -
Gert Doering -
James Blessing -
Jan Zorz ＠ go6.si -
Jasper Jans -
Jim Reid -
Mark Townsley -
Masataka Ohta -
Mikael Abrahamsson -
Nick Hilliard -
Nigel Titley -
Randy Bush -
Remco Van Mook -
Sander Steffann -
Sascha Lenz -
Shane Kerr -
Turchanyi Geza -
Wilfried Woeber, UniVie/ACOnet