On Fri, Oct 31, 2008 at 2:33 PM, <[EMAIL PROTECTED]> wrote: > Oh no. The way I would use geographical coordinates is completely > transparent to any geographical meaning (like continent, country, state,
and I read your example of driving or paper-mailing things pretty much as examples, akin to: "Route your traffic to AS1239, let them find the right internal place to deliver to..." which seemed sane enough, and in fact quite a bit like LISP or some of the other loc/id split techniques. > city,...) It is only a means to select the right "proxy destination node" > in the case that your true destination node is not yet "on your radar > screen". Based on it you determine the next hop. There is no change of the > economic make up. It is only that the next hop is determined in a different so yea, that again sounds like LISP... ETRs/ITRs... > and scaling way and can, in the data plane, be retrieved much faster than by > searching thru a 300 000 entries sized table. > 300k isn't so much a problem for most core devices today, 3m though... could be. > In a preceding email I once stated that the next hop determination (in the > data plane) takes only one single table offset lookup. Admitted, I have to > backup a little bit: If the destination is within a different spherical > rectangle (limited by two consecutive longitudes and two consecutive > latitudes) yes then it takes only 1 table offset lookup. However, otherwise how do longtitude and latitude matter for networks exactly? Save a few minor examples no one builds a network on lat/long boundaries... and often costs associated with paths in a network are more related to underlying fiber costs or peering costs than distances. > it will take 3. This wouldn't by any different even if the internet would be > a million times bigger. > > And this would only be the beginning for better routing: > With respect to a particular destination any router can subdivide its > adjacent links into 3 classes A, B, C. > Class A: the remote node is one hop closer to the destination > Class B: the remote node is equidistant away from the destination > Class C: the remote node is one hop further away from the destination > Multipath: With DV-based routing you can only use the links of class A. With > TARA you can also use the links of classes B and C - which includes > detecting whether or not the link leads into a dead end area, and/or whether > or not there is a chance to wind up in a loop and how to avoid it if > applicable. > how is route stretch measured? latency? jitter? how are services that depend upon lower latency and consistent (low jitter) latency supposed to survive in this climate? One of the reasons for the existing state in the global table (some of it at least) is for traffic-engineering concerns, I don't see the above scenario addressing those, but maybe you've just oversimplified. -chris _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
