Alain Durand wrote:
>
> Anyway, my point is that if this trial/error process of walking through
> the list of possible destination before finding a correct one can be
> extremely time consuming. So, if the "routing view" of the world
> is not in sync with the "DNS view" of the world, unacceptable delays
> may/will occur.
A fair comment.
Some workarounds (of varying levels of reasonableness):
(1) Make sure the DNS view (as seen by the application) is accurate.
(2) Try several 'likely' candidates in parallel.
(3) Have a good metric for picking 'likely' candidates.
This discussion of 'likeliness' moves us into the local vs global question.
Let's first assume that the application doesn't have special needs (like
address forwarding) and just wants a connection. If special needs exist
then the app may need to cull the list of potential addresses to suit.
If we already have a working connection between two endpoints, that's a good
candidate. Of course, this may require looking external to the application.
Ignoring this, what should we try first? Well, matching prefixes is good,
since they are most likely to work. The only other advice would be that
when connecting to and address we know is filtered to try to use another
equally filtered address (as they are both 'probably' in the same space).
Failing that, if connecting to an address beyond what we know about, try to
use a similar address. Which looks surprising like local-local, then
global-global (or try both at the same time).
--
Andrew White
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------