On 6-dec-2005, at 17:36, Oliver Bartels wrote:
To me, it's pretty obvious that if we can have aggregatable PI space, then that's an excellent reason to NOT have non-aggregatable PI space.
You may aggregatable PI space if you can convince the router manufacturers create and implement a new RFC which adds an additional layer for prefix aggregation within the BGP protocol.
I can't imagine what such a layer would look like...
Geographical aggregation however, is _for_sure_ not the solution for the new centrury. Geographical solutions happened in the last century.
In IP? Don't think so. If you have pointers, please enlighten me.
Nowadays carriers use DWDM technology, and yes, a link between Frankfurt and London or even New York is cheaper and easier to obtain than a link between Frankfurt and Wiesbaden.
Sure. But trying to aggregate on network topology is never going to work for two very simple reasons: 1. It changes all the time 2. You can't express a topology with loops in it in an addressing hierarchy The reason to choose geography to aggregate on is not because it is somehow magically always the best fit with topology, because it isn't. However, it has two very important things going for it: it's not subject to change, and it allows for optimization on distance, which in turn has the potential to be be good for cost and performance. Please don't assume you understand my proposal just because it contains the term "geography". If you want to know what it entails have a look at http://www.muada.com/drafts/draft-van-beijnum-multi6- isp-int-aggr-01.txt
The key issue is whether competing dark fiber or leased line carriers are available at a certain location and _not_ the distance between those.
Distance is actually very important. It's very hard to do decent high speed file transfer on out of the box OSes and applications with high delay. Also, it often makes sense to backhaul traffic over SOME distance, but that doesn't mean it also makes sense to backhaul it over even larger distances. I.e., even if a link to New York is cheap, you don't want to go over Palo Alto.
As routing was not really considered by the designers of the IPv6 protocol (yes, this _is_ an fault, IPv6 can be considered a lousy solution under this view), we can either live with it or give it up. Living with it means providing a solution for the PI requesting organisations and waiting for an aggregation enhancement of the routing protocols or keep it experimental, which probably means: Let it die.
Your conclusions don't follow from your assumptions. Yes, IPv6 doesn't do anything for routing except allow very large aggregates. However, the choice isn't between allowing unlimited growth and hoping we can fix it later and not using IPv6, the choice is between: - Not allowing PI - Coming up with aggregatable PI of some kind - Give up and make the exact same mess of IPv6 as we did with IPv4 Today, IPv4 routing works but it has come close to the edge of the cliff twice (early 1990s just before CIDR routing tables were too large and late 1990s flapping cost too much CPU) and it's still pushing towards that edge, which we can't see clearly but know is out there somewhere. And that happened in 25 years. We'll very likely have to live with IPv6 for much longer than that, so we HAVE to be careful from the outset. Shim6 is coming, aggregation with PI is unexplored, IPv6 is still in the extremely early stages, so this is NOT the time to do stupid things. If we're still in the same boat in 5 years when we're down to 18 months of IPv4 addresses, sure, we can revisit this issue. But we still have some time. Let's use it.
Even if the PI question is solved these days, I won't be sure if the answer isn't already too late. The market will tell us.
What kind of logic makes this too late?
I'd rather have a working internet without PI than a non-working one with it. Nobody can guarantuee that we won't run into trouble with PI so the only way we can be sure we won't have this trouble is to not have PI.
This argument is unreal, you can stop _any_ project with it, in Germany we call it "Vollkaskomentatlitaet" and our country suffers a lot from it.
Well, then apply some of that mentality to PI in IPv6 and free it up elsewhere. :-)
There is simply no way to prove that a given solution won't have a side effect.
So because you can't prove that you're right I should just believe you without proof?
If you write: "Nobody can guarantee ..." then I will tell you:
Nobody can _guarantee_ that your posting by its formating or content can't cause a significant harm to an important server, cause a worldwide crash of the internet, thus impairs water and electricity supply and at the end let the aliens conquer earth.
No, but there's no reasonable scenario that makes this happen either. The scenario that de facto unlimited PI in IPv6 will make routing tables so large that it becomes problematic in some way or another is entirely reasonable, on the other hand.
More realistic:
I'd rather like a internet with IPv6 and PI and the very low probability of of trouble which can with a high probably be fixed than no real- in-use IPv6 because of arguments which request gurantees that can't be given for _any_ solution on this planet.
Yes, I've heard it all before. Why don't we work on something that we can all get behind? The beauty of my geographical aggregation thing is that you still get PI even if it turns out that it doesn't work. So you get what you want regardless of who's right. Pretty good deal, don't you think?
Up to now engineers have always proven to find solutions for networking problems like the PI issue, thus there will be some solution for sure if required.
Sure, we can always implement some kind of aggregation later. This of course requires renumbering of all PI space. And isn't the idea behind PI space that you never have to renumber out of it...?
P.s. @RIPE NCC: Question: Is there a practical way to replace the slow and cumbersome "consensus" principle of the RIPE by a democratic majority vote of the RIPE NCC members to stop further damage to IPv6, perhaps with a decision at the next RIPE NCC general meeting ?
Please replace "RIPE NCC members" with "people who have to pay for bigger routers world wide" (not just the RIPE region) and I'm all for it. Iljitsch -- I've written another book! http://www.runningipv6.net/