The GERO address scheme perfectly contains the geolocation information which I requested as well, but was rejected by argumenting with "is not incrementally deployable" and "requires host changes". I can only confirm and even extend the list of positive results: The routing table entries will become very short (maybe 600 but certainly not more than 2-3 K ), the update churn will disappear completely, the such small routing table could be enlarged just for the sake of faster forwarding: just one next hop table lookup, offset by the respective geopatch number (note, that there are 360 x 180 =64800 geopatches which is less than 256x256=65536) in case the destination belongs to a different patch i.e. which is confined by different longitudes and latitudes), and certainly likewise while using another table for the next hop determination if the destination belongs to the same geopatch like the current router. In preparation, experimental RF C1712 has been published a long time ago, but never used and never properly read, not even by the RFC-editor: there, where the encoding is standardized, longitutes and latitudes are terribly mixed up :-( Note also that the one single table lookup may cover both inter- and intra-domain hops, will say that one lookup will do no matter how many OSPF- nodes may be the potential destination node. Note that the "<=" -compare operator is much more powerful than the "=" operator, and also note that geopatches are the only entities which are best suited for aggregation: much better than unicast addresses for sure (while AS numbers and Multicast addresses aren't at all !!!) Heiner In einer eMail vom 10.03.2008 12:23:17 Westeuropäische Normalzeit schreibt [EMAIL PROTECTED]:
On Mar 9, 2008, at 11:40 PM, Lars Westberg wrote: > Hi, > I haven't had time to make a draft but I think it make sense for the > discussion. However, I don't know if it already have been discussed > so.... > > The proposal are simple: re-use AS-numbers into the forwarding of > packets such that prefixes could be aggregated per AS. One simple > implemetation is that the packets are tunneled and that the tunnel- > address is associated to a AS-number. The AS-numbers can be assigned > to the IP-addresses by DNS or by define a small address-prefix to AS- > numbers. > > Comments? > in an ideal world, yes having AS number as part of address used for routing has great benefit. see the slide from a talk in 2006 (http://www.cs.ucla.edu/~lixia/0612Australia.pdf , but ignoring the title), slide 17 & 18 is about this. If we had a chance to influence address structure, you'd want to include other info in addition to AS (as large ASes span large areas, TE would want more info to do better job). we have another paper (http://www.cs.ucla.edu/~rveloso/papers/ giro.pdf) showing the benefit for including location info (which should be a subfield after AS number) FYI, Lixia -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
