Re: 200 customer requirements for IPv6
On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote:
There are lots of similar examples as the NATO one. It make no sense at all
Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done. Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done. Too simple, too scary, too much independence again to the endsites, eh? I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often). Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward. My 0.02EUR Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots) -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, Daniel Roesen wrote:
On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote:
There are lots of similar examples as the NATO one. It make no sense at all
Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done.
ok, *handraise* That's not entirely true - while i have "my" /32, i'm still arguing against this current no-PI situation every this and then (i stopped getting involed in _every_ IPv6-PI-related flamewa^Wthread long ago though...) But indeed, that's still the main problem, that people don't get their head out of the sand, largely due to just not seeing this problem as an issue for themselves.
Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done.
Too simple, too scary, too much independence again to the endsites, eh?
I think, the main argument against IPv6-PI _still_ is the routing table size, contradicting any reasonable predictions nowerdays (IMHO!). At least that was my own argument against(!) PI in first place, but times have changed since the last millenium. In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then. I can't even see any solution rising in the FAR future, so the only way to keep IPv6 from being completely useless is, go for allowing PI Space for organisations who really want that geniune kind of multihoming and are sure they don't want any workaround solution. A setup+renewal fee does not do much against the routing table size or so, but at least should stop having the IPv4-situation with swamp space(s) and unused, unowned or "joke" Prefixes floating in the databases. I wouldn't like to have anyone to get a Prefix without reasonable need just for the fun of it, like with el-chepo Domain-Names and Hostname ect.. One should know what he does. Of course the issuing organisation should point to alternative solutions and have the requesting one to check out on them if they might be sufficent for their needs (the famous "Did you consider using RfC1918?"-alike-question in the request form should do it with some pointers to good FAQs on alternatives).
I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often).
ACK. That's ridiculous. Additionaly, some might not NEED a /32 and don't want to pay for services they don't need (Registry servies, voting@RIPE-meetings, Training Courses... whatver)
Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward.
Well, if i say "there is no scalability" problem, that would be considered ignorant by most people, so i don't do that now. But i can't see any problems with BGP routing table size either, it will be significantly smaller than in the IPv4 world by design (one - or few - prefixes per AS), and even when it's growing again from PI-prefixes, probably beyond the current IPv4 table size, what's the problem? Nowerdays routers actually can handle that with >=1GB RAM and fast ASICs. ... and it will take YEARS if at all to raise above nowerdays size. Now let alone the fact that you need to carry on with the IPv4 table for decades anyways, so no relief in sight for the routers... But i'm not saying, there won't be a problem in 50years.
My 0.02EUR
I add another 0.02EUR
Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots)
...i rather invest in redundant Uplinks and routers than in becoming LIR for no apparent reason (i.e. not ASSIGNING Address space as primary purpose), hence i currently go for IPv4-PI for my non-profit organisation(s), utilizing a /40 Suballocation in the IPv6 world from "my" (commercial) LIR. Better than nothing but i'd prefer a completely independant IPv6-PI space and someone doing something against this /32-/35-filter-madness. "My" LIR is not very active in the ISP business lately, and i don't want to know how to deal with a CLOSE of the LIR with my more private, non-profit Address Space either. Am i allowed to keep the Suballocation when RIPE reclaims the LIR's /32? Can i announce the whole /32 when i can't reach some locations with the /40 Suballocation announcement? Can i have the whole /32 for free then not being a LIR? Do i ultimately have to renumber, too? How often? How do i maintain my multihoming properly? ...and so on...(NOTE: rethorical questions, i know the current procedures on the paper) <arrogancy> Idependency is one of the basic things in the internet, i don't like people who want to tell me how much independency i need. I know that best for myself. </arrogancy> -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
My apologies for replying to such an old message, but I couldn't let this one go. On 18-nov-2005, at 12:33, Sascha Lenz wrote:
In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then.
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago. The only thing I got was perplexed stares. You really can't expect to keep doing the same thing we've been doing in IPv4 in IPv6 but now with different results (= more reasonable routing tables). Iljitsch -- I've written another book! http://www.runningipv6.net/
Hi, Iljitsch van Beijnum wrote:
My apologies for replying to such an old message, but I couldn't let this one go.
On 18-nov-2005, at 12:33, Sascha Lenz wrote:
In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then.
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago.
Actually, i did pay attention, but why do you think i consider that as an equal solution to BGP Multihoming with "PI"-space? It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table. Why do i want this at all? Because there are globally distributed prefixes right now, there is no geographically based assigment in sight anywhere and yes your presentation was a while ago. IIRC even your presentation said that this would require geographically based assigments "right now". Right? Do you expect everyone with a prefix today to give it back and renumber? "Too late" at least for a full solution. This is just another suggestion that might be helpful for preventing some amount of global prefixes (see below), but not god's own solution to the problem.
The only thing I got was perplexed stares.
You really can't expect to keep doing the same thing we've been doing in IPv4 in IPv6 but now with different results (= more reasonable routing tables).
*think* Of course... as mentioned before by many people, IPv6 implicitly solves some of the problems with "too many routes". Again, this leads to: - "usually" only one Prefix per AS even with nowerdays IPv6 policy ==> "more reasonable routing table" per default because almost noone needs a second Prefix - no impact on the IPv4 Routing Table size which you have to carry around for decades anyways. ==> no relief for any router in sight, regardless of the the IPv6 policy - There _ARE_ multihoming solutions besides world-wide prefix announcements, there are many. You can suggest all of them to your customers when they ask for "redundancy" or so. You even could be required by policy to tell your customers about the solutions as i suggested during the current thread. BUT - if someone insists on BGP Multihoming with worldwide prefix distribution for whatever reason he/she might have, noone must be forbidden to do so! ==> Even less End-site-customers who want an AS and PI-Prefixes because some actually _ARE_ OK with alternative. Noone denies the fact that there are most likely too many prefixes and probably even too many ASes in todays IPv4 Internet Routing Table. It's also a fact that many of them are not really needed, and the desired redundancy could be achieved by other means. Some customers might even be happy if they don't need to care for BGP Speaking Routers or so in their network and are pleased if you suggest a different solution. The main problem is just people who want to tell "me" (not literally) what's best for "my" network, and disallow "me" in the pond with the big fish. ..and there are absolutely no technical reasons which would forbid "me" in this pond if i want to swim there. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
On 6-dec-2005, at 15:59, Sascha Lenz wrote:
In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then.
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago.
Actually, i did pay attention, but why do you think i consider that as an equal solution to BGP Multihoming with "PI"-space?
I don't understand what you're trying to say... But I'm happy that someone noticed what I was trying to say back then.
It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table.
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. Note however that the aggregation is optional in my plan: everyone can implement it in their own network independent of what everyone else does. In the beginning, there certainly won't be any reason to aggregate so this type of PI is completely equivalent to regular PI.
Why do i want this at all?
Well, I don't know. I can get by with my PA /48 just fine. But apparently some people like to multihome and some of them insist that shim6 doesn't address their needs. And others want a portable prefix for other reasons.
Because there are globally distributed prefixes right now, there is no geographically based assigment in sight anywhere
So? If we really want this we can start doing this in a manner of weeks: the only requirement is that the RIRs start giving out prefixes that are aggregatable. In practice, it will take about the same amount of time as any other policy change.
Do you expect everyone with a prefix today to give it back and renumber?
Today, there is no PI in IPv6 so that's a moot question.
BUT - if someone insists on BGP Multihoming with worldwide prefix distribution for whatever reason he/she might have, noone must be forbidden to do so!
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. If you want PI as it exists today in IPv4, the burden is on you to show, yes, SHOW that it can scale for decades to come.
The main problem is just people who want to tell "me" (not literally) what's best for "my" network, and disallow "me" in the pond with the big fish.
Do whatever you want, as long as you don't do it in my routing table. The internet only works as long as 99% of all people carry 99% of all routes. When a sizeable number of people starts filtering a sizeable number of routes for whatever reason, either technical (won't fit in their routers) or political (don't agree with the policies) then we're in knee-deep brown stuff. -- I've written another book! http://www.runningipv6.net/
On Tue, 6 Dec 2005 16:30:25 +0100, Iljitsch van Beijnum wrote:
On 6-dec-2005, at 15:59, Sascha Lenz wrote: [...]
Well, you haven't been paying attention, because I've presented "provider-internal aggregation based on geography" at two different RIPE meetings a while ago. It's _ONE_ alternative solution one might suggest, but still no reason for disallowing anyone in the globally distributed prefix table.
Ack.
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. Geographical aggregation however, is _for_sure_ not the solution for the new centrury. Geographical solutions happened in the last century. 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. The key issue is whether competing dark fiber or leased line carriers are available at a certain location and _not_ the distance between those.
Well, I don't know. I can get by with my PA /48 just fine. But apparently some people like to multihome and some of them insist that shim6 doesn't address their needs. And others want a portable prefix for other reasons.
Yes, and as these people make a significant part out of the IPv4 internet world, as ISP's we can either support their requirement or keep IPv6 experimental. Period.
So? If we really want this we can start doing this in a manner of weeks: the only requirement is that the RIRs start giving out prefixes that are aggregatable. In practice, it will take about the same amount of time as any other policy change.
The key issues is: What today might look like an aggregate, won't be one tomorrow. Today A might be related to B and C to D, thus (AB) or (CD) might sound like good aggregates, tommorow A is related to C and B to D. Math limits the aggregation possibilities for ABCD. In this case, a bit mask could help: (A=x00y, B=x01y, C=x10y, D=x11y, thus first case mask 10, second 01) but it is obviously not possible to find an aggregation solution for any possible combination (e.g. ABC vs. D). 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. 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.
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. There is simply no way to prove that a given solution won't have a side effect. 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. Thus you shouldn't post to this list ... Of course this is very very unlikely to happen, but, who knows, a word sequence within your comment might trigger this by a unknown bug within a common microprocessor type. You can't gurantee that your posts don't harm, thus by your own logic you should really consider not to post anymore ... 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. 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. However I doubt there will be ever this requirement.
Do whatever you want, as long as you don't do it in my routing table.
You are free to implement _your_ routing table as you like and to filter what you like, however: The global routing table is not _your_ routing table. Please don't block further enhancements of the Internet and please don't damage IPv6 by spreading out FUD. Thank You! Best regards Oliver Bartels 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 ? Of course some RIPE participants might then discuss adresss policies for ever, but for the RIPE NCC members we would then probably have practically acceptale policies for implementation in real world networks. Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
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/
On Tue, 6 Dec 2005 18:08:40 +0100, Iljitsch van Beijnum wrote:
On 6-dec-2005, at 17:36, Oliver Bartels wrote:
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...
Clustering all PI-prefixes originating at the same AS to form a single "super-prefix" makes policy processing a lot easier, because it need to be done just once for the whole block. This is obvious for single homed PI and even saves processing time on multihomed PI. Whether the address space occupied by this prefix is homogenous or not is a "don't care" nowadays, as a large forwarding table isn't a problem at all. With as few as 256MByte of DDRAM plus a 64K TCAM chip it is possible to handle max. 8 Million Forwarding entries at full 128 bit resolution with appx. 10 GBit/s typical and 1.5 GBit/s "bad weather" (small packets only) line rate. I personally just received a patent on such router hardware concept.
In IP? Don't think so. If you have pointers, please enlighten me.
In POTS and X.25 networks. The latter died ...
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
The same is true for geographical aggregation. Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models. There is no free transit and thus it doesn't work. Business relations changes all the time and in a global markets world these business relations don't stop on country boundaries. Such boundaries are artifical, the EU tries to avoid them. Thus the only aggregation you would gain is: Americas / Europe-Asia / Asia-Pacific. Not even Africa and with huge problems in Asia. Everything below this continental boundaries can be treated local and, with your own words : It changes all the time ( Why: See below, dimensions. ) Thus with a geographical approach your aggregation gain is near zero (might be a factor of 2..3 in the table, which is near zero in this context). Sorry, but geographical aggregation won't work in these days any more.
2. You can't express a topology with loops in it in an addressing hierarchy
Avoiding loops is the job of the routing protocol, not the topology.
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.
If I would be located in Seattle, Palo Alto might be an alternative way point as well as Chicago or even Dallas. What you are trying is: Map a two-and-a-half-dimensional world on a one-dimensional address range. This won't work by Math. Dimensions can only be replaced by dimensions. Asked a database programmer how difficult it is to implement a geographical 10km around some place search on a database and ask them about the algorithms in use. What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions, like: X_MSB Y_MSB X_2SB Y_2SB X_3SB Y_3SB ... However this requires a _significant_ exception handling effort, nothing someone would like to implement in a fast forwarding engine for packet routing. Beleave me: The cost for 256MBytes of DDRAM is in the lower two digits Euro range, nothing to be discussed with high end routers. A large forwarding table is much cheaper than a geographical packet resolution.
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.
It works. Period. And it will continue to work, because of the economic pressure. Engineers have found a solution, thus: Don't worry.
So because you can't prove that you're right I should just believe you without proof?
Yes, because the theory of computer sience gives you the prrof that there are theorems in this world which can't be proven. Computer Software belongs to this sort of items, someone can just test it, make assumptions, but can't prove it will be correct for any but the most simple algorithms. And this is proven. Try to build an algorithm which checks that any other algorithm will correctly terminate. Try to apply this algorithm to itself, think about the consequences and then you might understand: Real technology is always believe at some point and not proof. There is no way to get a _proof_ that your post (or my) doesn't trigger a nasty CPU or router operating system bug which causes the internet meltdown. There is just believe and trust that reasonable router manufacturers will deliver reasonable products.
No, but there's no reasonable scenario that makes this happen either.
Of course there is. Think of the nasty multiplication bug with the Intel 486 CPU. This happened just with a few numbers. Intel replaced a huge amount of these chips free of charge. Think of a race condition in a chip, which processes your post and creates a checksum. Under very rare circumstances the race condition applies for your checksum (see multiply bug), cascades to a bus collision and melts down the router. However the forwarding hardware already received the ok to output the dangerous packet to the next router in the chain without further intervention of the hardware which just died.
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.
The current experience let us make a reasonable and responsible assumption that a IPv6 routing table would take not much more growth than the current IPv4 table, whereas current technology permits tables of 10 to 100 times that size.
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?
Again: 2 dimensions -> 1 dimension doesn't work.
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.
People who pay for big routers pay for big pipes, too. They pay significantly more for big pipes than for big routers. If you give them the choice to save 10% on the pipe for using the cheaper offer instead of the one-dimensional-geographical ordering-correct offer, and increase the router price by 30% percent for increased routing flexibility and larger tables, they still will vote for the cheaper pipe. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver@bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0
On 6-dec-2005, at 20:10, Oliver Bartels wrote:
I can't imagine what such a layer would look like...
Clustering all PI-prefixes originating at the same AS to form a single "super-prefix" makes policy processing a lot easier, because it need to be done just once for the whole block.
I'm not sure I understand the "superprefix" but obviously a lot of work that now happens per-prefix in BGP should happen per-AS. But that's mostly moot in IPv6 as we should never reach the numbers of prefixes per AS that we see in IPv4.
With as few as 256MByte of DDRAM plus a 64K TCAM chip it is possible to handle max. 8 Million Forwarding entries at full 128 bit resolution
I guess that means you throw everything in the TCAM first to get from 8M to about 125 entries and then look those up in a tree or hash table? Obviously it's possible to build architectures that allow fast forwarding with big tables. However, this doesn't come free: it takes more iron to do this, and also more power. TCAMs suck down the juice like a depressed alcoholic. This is bad for your design (both the box itself and the datacenter), your wallet and the environment.
I personally just received a patent on such router hardware concept.
So big routing tables are good business for you, then?
Sure. But trying to aggregate on network topology is never going to work for two very simple reasons:
1. It changes all the time
The same is true for geographical aggregation.
I guess I you live in California or another place that is plagued by frequent earthquakes...
Geographical aggregation would require free transit, otherwise it is not compatible with the ISP's business models.
The point is to keep the aggregation inside the ISP network. Tier-1 ISPs would still have a full routing table, but rather than have a copy in each router, it's distributed over the network. So there is no free transit requirement.
country boundaries.
Such boundaries are artifical, the EU tries to avoid them.
The idea behind aggregation is that you can move up or down. If country borders get in the way, drill down a bit and start looking at provinces or cities. In our design there are potentially 64k distinct areas (mostly cities) so if you want, you can have a route for each of those in your routing table and never run into country borders.
2. You can't express a topology with loops in it in an addressing hierarchy
Avoiding loops is the job of the routing protocol, not the topology.
??? Are we talking about spanning tree now? Loops in the topology are good. You can't remove them. Routing is also dynamic, BTW.
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.
If I would be located in Seattle, Palo Alto might be an alternative way point as well as Chicago or even Dallas.
Of course. But we're in Europe. If you're in Seattle you'll see a lot of your traffic to other people in Seattle flow through Palo Alto. That's normal, because it's not economical to peer with everyone everywhere. It's not so cool when intra-Seattle traffic starts to flow through Miami.
What you are trying is:
Map a two-and-a-half-dimensional world on a one-dimensional address range. This won't work by Math. Dimensions can only be replaced by dimensions.
Ah, but we're not mathematicians but engineers. In software, you have one dimensional memory. Still, you can have multidimensional arrays.
Asked a database programmer how difficult it is to implement a geographical 10km around some place search on a database and ask them about the algorithms in use.
Easy: select everything that's in a 20x20 km grid around the center point and then do the real distance calculation on everything in that grid. Obviously you'll select stuff that's at x+8 y+8 = ~12km from the center but that's only true for a relatively small part of the intermediate results.
What they try is interleaving the West-East (X) and North-South (Y) coordinates bitwise in the search key and handle overruns by exceptions,
That sounds like Tony Hain's geographical addressing. The variant Michel Py and myself came up with is based on administrative borders such as countries so you already have on dimension: the alphabet. (Ok, not entirely how it works, but still.)
However this requires a _significant_ exception handling effort, nothing someone would like to implement in a fast forwarding engine for packet routing.
Geography is long gone by the time we're forwarding packets.
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.
It works. Period.
Hm, if you only descern "works" / "doesn't work" it's hard to say anything about the routing system... Some quantitative and qualitative analysis can be helpful.
And it will continue to work, because of the economic pressure. Engineers have found a solution, thus: Don't worry.
Guess what. I'm an engineer. I'm working on this stuff. And I'm saying: when de facto unlimited PI is allowed, it may not mean the end of the internet, but it's certainly reason to worry. Of course things will continue to work. However, they'll be less reliable and more expensive.
So because you can't prove that you're right I should just believe you without proof?
Yes, because the theory of computer sience gives you the prrof that there are theorems in this world which can't be proven.
There are also many theorems that turn out to be false. Proof is a pretty good method to avoid those. If we can't have proof we'll need to have less reliable methods to avoid them. Just accept anything is not the solution.
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.
The current experience let us make a reasonable and responsible assumption that a IPv6 routing table would take not much more growth than the current IPv4 table, whereas current technology permits tables of 10 to 100 times that size.
Today, people sometimes deaggregate a /16. That's bad: 255 unnecessary routes. What if they do the same thing with a /32 in IPv6? 65535 unnecessary routes. That will probably kill most existing IPv6 routers today. 10 times is 1.75M routes, 100 = 17.5. The former is probably doable for IPv4 on some extremely high end boxes but I'm not sure how those would handle real issues such as flapping, lots of full feeds etc. I don't believe the latter exists or will exist in the forseeable future, at least not in a way that anyone can afford to actually use. Even those 1.75M boxes will be very expensive and only affordable by the largest networks. Don't forget you and I all pay for their hardware, directly or indirectly. Iljitsch -- I've written another book! http://www.runningipv6.net/
participants (4)
-
Daniel Roesen -
Iljitsch van Beijnum -
Oliver Bartels -
Sascha Lenz