|
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 RFC1712 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
lixia@CS.UCLA.EDU:
On Mar 9, 2008, at 11:40 PM, Lars Westberg wrote: |