[ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6

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 at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0