On Tue, 6 Dec 2005 21:42:57 +0100, Iljitsch van Beijnum wrote:
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.
Yes. As typically all prefixes of an ISP are impacted by an upstream pipe break, it would make sense to bundle them together by the means of a protocol item and perform updates on the bundle/super-prefix only for as much operations as possible and use incremental superprefix member operations. This could be made hierachical, but on a protocol layer, not by a fixed adressing policy. It would save computing time on updates which is an issue.
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?
A bit different, otherwise it won't be an invention. DDRAM's have a special characteristic that helps a lot.
Obviously it's possible to build architectures that allow fast forwarding with big tables.
Yes.
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.
No. FUD only. A small single height eurocard is sufficient which draws less power than an average PC.
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. [...] 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.
Even we as a small ISP don't care about _city_ boundaries, they are absolutely irrelevant. In some cases there is no routing at all, it is just switched. Again: Country/City etc. boundaries are irrelevant, we have a directive in the EU which permits telco operation from any company in any member country in any other member country without license. It is just "hello, we do it now" registration. If an ISP specialises in the Elsass, it is likely that half of the net is in France and half in Germany. On the other hand for historical/business relation reasons our net is partially Bavaria and Baden-Wuerttemberg. The next ISP will support Bavaria and Saxonia, or Bavaria and Hessen (very likely due to existing infrastructure, I know several), than again Hessen and Baden-Wuertemberg, or Saarland, Luxembourg (nearby) and Hessen (DeCIX pipe, just taking additional customers there). Don't forget Bavaria and Austria, Bavaria and Switzerland or Austria and Switzerland. There is simply no mathematical consistent way to aggregate this by administrative boundaries. I am a friend of clear wording: Your RFC-suggestion paper is not functional in practice. Sorry for your paper, but math, physical laws and law's of economy don't care about personal oppinions expressed in papers.
??? Are we talking about spanning tree now? Loops in the topology are good. You can't remove them. Routing is also dynamic, BTW.
Again: Loop removal is the job of routing protocols, thus BGP contains a path attribute. As long as there is a usable and unrestricted (transit) connection, it works, as the Internet proves every day. We don't need to discuss problems which do not exist. Problems will arise if you arbitrarily split the routing table as you sugest in your RFC proposal. Thus simply don't do it and the problem is solved.
Ah, but we're not mathematicians but engineers. In software, you have one dimensional memory. Still, you can have multidimensional arrays.
Engineers should consider mathematical laws, otherwise they produce low quality. You may store multidimensional arrays, but this doesn't help you here in this task, which is exactly what your "algo" would require:
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.
Aha: We take the already available solution and then do some additional calculation to present it ... No, if you sort the data inside a grid, you have to consider the eight neighbor grids, too, thus _nine_ checks. The grid size is fixed (we are talking about a database), which is very similar to the geographical address-policy problem: It is fixed, too. The grid works fine only for distances below the grid distance and not much below that, it requires nine grid cell checks for a single query etc.
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.
Obviously you have to consider neigbour grids, which is exactly the same problem as with the adressing policy: You have to consider neighbour countries, cities etc. with totally different prefixes in your model. My definately last argument to explain it, thereafter I will consider it as "trotzdem" and won't give further arguments: There is no reason to put Kehl and Strassbourg (Eurobridge) in different routing tables because they are in different countries. It is just a cable over the Rhine.
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.)
Administrative border are _artificial_, the laws of math and economy don't care about them. Sorry, but for a working geographical adressing you would have to take a different scheme and even if RIPE would issue some address space based on interleaved coordinates you will find that even a geographical range search is a non-trivial task a router won't do on the fly. It takes much more computing power than a large table.
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.
It definately doesn't mean the end of the internet, other RIR's issue PI, too. You might worry that an asteroid will hit us tomorrow, but this is not the issue of the address policy wg.
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.
Today they can do. 1,75M is expected (except vendors with a customer-should-buy-new-box-because-we-limit-resources-by-company-policy attitude), 17.5M is really high end, but sounds not impossible.
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.
We pay much more for pipes than for hardware. 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