Re: [RRG] incrementally deployable

Philip,

Please excuse my ignorance about DAG and TORA, so I can't say anything about.

I use the following colors: blue = Dijkstra best hop, red = equally best, yellow= remote node has the same distance to the red destination node. Because in this example all link weights are equal 1, therefore there is no green arrow, with green = get closer to dest. but not as close as by a blue or red arrow.

My picture doesn't show any hierarchy. It only shows the effects of this elementary algorithm which however is needed to compute topologies of upper hierarchical levels.

My favorite is "topology follows addressing", but I guess this remark doesn't help you much without knowing the entire solution - which indeed does not just improve scalability but abolishes this problem. Not only for now, but forever.

Thanks for your interest, anyway.

Heiner

In einer eMail vom 07.11.2007 17:03:43 Westeuropäische Normalzeit schreibt philip.eardley@bt.com:

Heiner

I for one would be very interested to learn about your ideas.

I followed your challenge about following the sequence of arrows (the first part of which was to find the right page to look at on your web site!!) – and indeed I ended up at the red node. So your approach is devising a Directed Acyclic Graph? I worked a bit on the TORA routing protocol, which formed DAGs so would be interested to hear how similar /different it is. why are your arrows multi-coloured? How does it work when the topology changes? Where’s there’s a choice of next hops, how do you decide which to use? Earlier you said that the alternative routes would use different ISPs, how is this reflected in the DAG?

You earlier implied that your approach is hierarchical, where does the hierarchy come into it? [your red node picture doesn’t seem to have a hierarchy]

You mention Rekhter’s law: addressing may follow topology or topology may follow addressing but choose one. Which one would you choose? Why? Nb at least some of the rrg proposals are trying at a high level to do this – splitting locator & ID to allow more freedom on how the locators are assigned so that they can follow the topology more closely [better aggregatable] and hence improve scalability of routing tables. Do you agree?

Sorry for all the questions, would be very interested in the answers!

Ps I expect you know - when the EU judges research proposals ‘Scientific & technical excellence’ is worth 1/3^rd of the marks, so it’s quite possible for proposals to score well in this category and still fail. Which can be frustrating. Do you have plans to submit a proposal with similar technical scope?

Thanks

Best wishes

Philip Eardley

-----Original Message-----
From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf Of HeinerHummel@aol.com
Sent: 07 November 2007 13:16
To: bortzmeyer@nic.fr
Cc: rrg@psg.com
Subject: Re: [RRG] incrementally deployable

In einer eMail vom 07.11.2007 12:08:26 Westeuropäische Normalzeit schreibt bortzmeyer@nic.fr:

URL where I can download a text file / HTML page / PDF document /
whatever? Otherwise, I would not be the only one to think it is purely
handwaving...

I can assure you that this concept (which needs algorithmical computation of topologies) is based on what you can see on my website's sample network diagram, where all links are converted to arrows. The result may be called Multipath Direction Field, or may be called All Links Spanning Tree (ANST). All blue arrows form an ALL Nodes Spanning Tree (ANST) which is simply the Dijkstra shortest path tree and which is part of the ALST resp. MPDF.

The ALST resp. MPDF is just a starter. It will impact ipfrr as well as the more important current RRG-topic, plus more.

As to find out whether this is just hot air or not, choose any sequence of arrows you like and try not to wind up at the red node. Only if you can accomplish this or if you can detect any single loop of arrows, I will apologize...

Heiner

www.hummel-research.de