I don't mean to imply any push-back against this approach, since I haven't yet adequately read and studied it. However, when we talk about Internet-wide scaling on schemes such as this, I would think that a desirable attribute would be to know the local links well, but to know much less about remote links (e.g., which network interface to forward packets on). This could be accomplished by a variety of technologies (e.g., Hazy Sided Link State; Landmark routing; Fisheye Hierarchical Routing; etc.). However, the affects that I am naively suspecting that would tend towards greater scalability would be to have results that resembled link state (Dykstra) computations for local links (e.g., whatever grouping is decided to be "local"; whether regional, country, continent, or some other definition of proximity) and Bellman-Ford-like results for remote (i.e., non-"local") links.
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 20, 2007 3:10 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [email protected] Subject: Re: [RRG] Idea for shooting down In einer eMail vom 20.11.2007 23:32:31 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]: Tony, Brian, Each node has to see a network topology where this node is surrounded by nodes and links, whereby the more remote the looser the links, whereas the nodes are all individual routers (even those at highest hierarchical level !!! ). The length of each link between any two nodes is precisely determined due to the routing protocol which builds this hierarchical topology. I expect that the length of some hierarchical link is according to the number of physical link hops in between the two adjacent nodes (not the geographical distance in miles or km, which could be done as well, e.g. in order to build a disk for worldwide car navigation ). What is needed: for each viewed node its geographical coordinates (proper degrees, not the minutes or seconds) and the destination's geographical coordinates, likewise, which would take 3 parameter octets in the IPv4-header. DNS lookup should provide this info together with the IPv4 address. I hope, the ingress host can put the geo-info into the IPv4-header, or at least some proxy who is close to the source user and has cached what he has learned from a passing DNS query. But then the real (strict) next link determination can be done even if the destination node is not on the radar screen :-) but just some other node with geo-data closest to the destination's geo-data. So routing, fairly as close as we want by design, can be done without any reachability info evaluation. It could be done such close that the last few hops can be done just like in OSPF, where each passed node forwards based on the reachability info of the egress node, or, if you want, by using classic BGP, however with a small routing table with geographical square degree- wide unique address prefix. Heiner On Nov 20, 2007, at 2:15 PM, Brian Carpenter wrote: >> Imho, it could be so simple. Sometimes I compare my situation with >> Platon's cove story. Because I am not so good in BGP I am bad in >> interpreting the shadows on the wall, hence my model is ignored. > > Please point us to a document describing your proposal. The > animation on > your site doesn't explain NIRA in a way that I can understand. To be fair, Heiner did indeed give a conceptual overview to the mailing list. If I understood it correctly, it involved geographic routing at the top levels, based on longitude/latitude, with prefix routing locally. What I found unclear was how hop-by-hop forwarding worked while packet addressing continued to be strictly address based. I await further enlightenment. Tony
