In einer eMail vom 10.11.2009 16:26:22 Westeuropäische Normalzeit schreibt [email protected]:
> From: [email protected] > Yes, but do hierarchies right. > ... > I have my doubts that the routing folks have a proper understanding wrt > hierarchies. This is probably true, because we just haven't had that much experience with them; the _very_ limited amount of hierarchy in use in the current system is just not enough to fully educate us about them. (I'd like to make an analogy to congestion control - back in the '77-'79 time period, not only did we not know much, we didn't know how much we didn't know... Well, a few people probably had a clue, but the rest of us did not really... :-) But I do think this particular topic is something that the RRG _should_ be thinking about, since it's closer to what I think a 'routing research' group should be thinking of. Fine. I can promise: It is not just about reducing some ugly aggregation material. It is also about enabling Moore's law. And even better: Given that you can index the best next hop information by ONE offset info as taken from the packet header (similar to MPLS), you can also do temporary reroute by the same speed: by just storing the temporary alternate next hop info at that place where as a default the very best next hop info would be placed. (plus a long list of more advantages). (The location/identity separation stuff is not, to me, really routing - it's more basic architecture, but since the I* doesn't seem to have a forum for basic architecture discussion, it seems to have wound up here...) I fully agree. > What it takes is a "sliding hierarchy" as provided by TARA so that each > router is fairly in the middle of the hierarchy and never at the very > rim. Sorry, I don't know enough about TARA to respond to this. Your Istanbul analogy didn't really help me much. Can you say more? Well, being a godfather of PNNI you ought to understand the Istanbul-analogy :-) > Hierarchy is by no means a reason to enforce a path which is longer > than the shortest one! True, but.... it seems to me fairly fundamental that the basic idea behind hierarchy and routing is that it allows one to discard _some_ information, to make the amount of data one has to process in the path-selection computation more reasonable. That being the case, it seems inevitable that _some_ stretch (over the theoretical minimum) should result. While being in the USA you should really discard the info about streets inside European villages (better: you should not even get them). At the same time you should definitely NOT discard any physical link which directly interconnects some place in America and another place in Europe. In the end, it is better to speak of a hierarchically sparsed flat topology ! So I use the term hierarchy only because this term is better understood by the readers (imho) Noel wrote: To return to your real-world map analogy, nobody planning a trip from Madrid to Gdansk goes out and obtains a map that shows _every_ road in Europe, and does their path-selection based on that. Any realistic approach would use 'high-level maps' from which many of the minor roads have been omitted. However, ignoring those minor roads may result in a path which is longer than the theoretical minimum. This depends on your concept. If you want to go from Istanbul-West to Istanbul-East and your hierarchically upper map recommends you to go to Ankara (or even Teheran) first before being able to appreach Istanbul-East then you will have this ugly stretch factor. Noel wrote: (And yes, I know, a theoretical-minimum length path would probably be slower than a path which took the larger limited-access highways... most people want to optimize time, and the road system itself has been designed to optimize that goal, e.g. with the constuction of those larger limited-access highways, so in the real-world there's an interesting interaction between the map-abstraction process and the infrastructure planning process - maybe the network world needs to do something similar?) Well this is state of the art. To play with the weight values of the edges. Heiner
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
