In einer eMail vom 02.12.2009 00:55:43 Westeuropäische Normalzeit schreibt r...@firstpr.com.au:
Short version: Heiner has not given any explanation of TARA. I think I presented a lot of details wrt the goal to be accomplished: get a well reduced map of the internet's topology so that based on the destination's (known) geographical coordinates the proper next hop can be determined even if the node with these coordinates wouldn't even show up on this map. Sure, there are more details, but knowing them won't help as long as people are not willing to give up the old paradigms which is aggregating addresses, aggregating nodes, aggregating ASes (right?), i.e. forming the wrong hierarchies. Just have a look to some actual LISP thread. Or see draft-zhang-zhang-evolution-02.txt - it contains suggestions about compressing the FIB which imho should rather be addressed to the idr-WG where they should be welcome unless they are already common practice. I pointed out that the postal mail does not do address prefix aggregation and can easily cope with a 100 000 bigger network of streets. Node aggregation: PNNI did node aggregation resulting in hierarchical nodes which then needed node-internal topologies ;-( And isn't ILNP eager to deal with AS aggregation ? (I don't know for sure and I even don't want to waste time looking at such ideas). I admit, PNNI has been my background, but today I know that topology aggregation is the only right way of doing aggregation. However, not even the new term "topology aggregation" could stimulate the curiosity of the researchers of this routing research group. When I explained how to hereby enable shortest path forwarding, the reproach was I would be unaware of policy routing. Did I mention "hierarchy" (although only the process to collect the data is somehow hierarchical) then, the stretch argument was raised - though that would indeed be appropriate for only all the other hierarchies (PNNI, ISLAY, ILNP,...). Did I use the words "eliminating" or "abolishing" the scalability problem, I was told that only "reduction" is at stake. We discuss all kind of identifiers but not which identifiers would be best for JUST routing. Robin, you yourself boast with not needing an own namespace for routing. I would rather see such a namespace which is JUST for routing. At last I thought, in view of the mobility topic, that no one would stubbornly stick to mapping routable GPS-info to non-routable addresses. But the reaction is once more silence. Yes, absolute silence, although we are going to see millions and billions of mobile internet-accessible handsets. All these aspects (and many more which I have come up with) have been ignored over the last few years and are still being ignored as if the task of the RRG is to block successfully any better and scalable routing. Heiner Hello Heiner, Thanks for your response in the "Constraints due to the need for widespread voluntary adoption" thread. Since it concerns your proposal, rather than the constraints, I am responding in a new thread. You wrote: > I am accrediting to you your emphazising that: > > a) incremental deployment cabability is a MUST "Incremental deployment" means different things to different people. We debated this in the past and I found that for many people, it just means that a new system can be introduced without disrupting the existing system. What is needed for voluntary adoption of a scalable routing solution goes far beyond this. http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ Constraints 1 to 5 involve end-users of the new system being fully able to communicate with users who have not adopted the new system - in both directions, including with the non-upgraded user's host initiating the communication. This is a far greater constraint than what many people understand by the term "incremental deployment". Here is one message from that discussion thread: http://www.ops.ietf.org/lists/rrg/2008/msg00957.html > b) that any higher level architectural objective must be backed by > the respective detailed solution. Indeed! > ad a) I completey agree. I do claim this for TARA. By the same token any > other competing solution can be deployed incrementally - CONCURRENTLY ( > so I hesitate to promote the competing solutions :-). OK, but you need to describe TARA in a manner which enables people to understand how it would work, and how users with non-TARA hosts (if it involves any host changes) in non-TARA networks (if TARA involves changes to end-user or ISP networks) can communicate with hosts using TARA. Your website: http://www.hummel-research.de/ is of no use to me, or I suspect to anyone with a detailed interest in scalable routing. The total text content would fit on an A4 page, but is divided into multiple Flash pages. You have never given a detailed account of TARA on this list as far as I know. Please present your work in text, or HTML - and ideally as an Internet Draft - if you want me to consider it. The remainder of your message contains no explanation of TARA whatsoever. If I ask you to give details of how you are going to design, build and ride a motorbike over some mountain tracks, it is not good enough to respond with a short story about how mountain goats navigate their territory. - Robin > This group think that it holds all the marbles in the own hand. Wrong. A > e.g. (most and forever) scalable solution can be deployed even > unnoticed. BGP provides everything that is hereby needed. > > Therefore I don't feel urged to participate in the race of soliciting > the own solution within the next few days. > > (and you shouldn't either ) > > ad b) > > I think the same way. So, be assured whenever I take my mouth full, > either by boasting what TARA can accomplish or by harsh critizising > other more-liked solutions or by emphasizing important requirements, > > It is always backed by the knowledge about the detailed solution. > > In einer eMail vom 01.12.2009 13:05:22 Westeuropäische Normalzeit > schreibt r...@firstpr.com.au: > > I have never been able to understand what you keep mentioning about > geographic mapping, or "location-namespace" etc. Can you give a > practical explanation of how it would work, with a different thread > subject than this one? > > I did give a practical analogy: The tourist who wants to go from Munich, > Karlsplatz (Germany) to Sausolito, Mainstreet California equipped with > maps of the current city, county, state, country, continent and the > world map. He will be able to determine the next hop although his > destination doesn't show up on any of these maps.With what I have in > mind he will be able to compute a flat map which combines all of these > maps, and how you would get them, e.g. such that any direct link let's > say from Munich airport to S.F.airport is included while thousand > others, e.g. like Vancouver to Seattle, aren't. > > But so far I have to be patient ( after all, it is only my personal > solution, meanwhile without any partners - a situation which I think you > share with me:-). No one is interested in better routing technology > although, for instance, a similarly reduced map wrt the sum of all > areas of an OSPF network might as well be of interest ( I think, though > I don't care very much about this side effect in view of the importance > of a future routing architecture ). > > How would your system enable non-upgraded hosts or upgraded hosts in > non-upgraded networks communicate with the devices using your system? > This is my question 3: > > http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ > > Well, see ad a) and also let's see what the leaders of this group will > recommend. > > How would traffic using your system traverse the DFZ? This is my > question 6. > > Definitely most capable, i.e. capable to take the shortest route, or any > detour (see the picture on my website; unfortunately it doesn't show the > entire set of detouring possibilities - but I could compute you some). > > No one can do magic tricks. There is a wide area of work waiting for > all. Example: The shortest route to the destination at almost the other > side of the globe be westward bound. I decide to go eastward. For the > next few routers the westbound route is still shortest. how do I > indicate that they should comply with my initial decision? Though I > haven't even looked closer to this scenario, I am optimistic to find a > solution.But I cannot see at all how the current routing > technology would even scratch at this issue). > > Heiner
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg