[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Stateless DNS discovery draft




> The pedantic answer is no, routers are not necessarily intermediaries
> according to my definition of that term.  Intermediaries are entities
> or sets of entities that a seeker sends *to* and/or receives *from*,
> in order to acquire needed info about a target.  If those entities are
> not on the same link as the sender, yes, you need routers to enable
> that sending and/or receiving, but the routers themselves are not the
> destination or source of the seeker-intermediary communication (unless
> a router coincidentally happens to be the home of either seeker or
> intermediary).

But in comparing a router that forwards packets to a well-known
unicast/anycast/multicast address (a L3 intermediary?)
and a router with a DHCP relay (a L4+ intermediary) there
are significant similarities. The main differences seem to be:
 - a router failure in the first case can be repaired without
   telling the host application to try a different address, which may or may
   not be the case when using a L4+ intermediary.
 - there exists a routing protocol which is an efficient way to get the
   intermediaries to find the targets.

But because of routing transients when the set of targets change the L3
intermediaries will have stale information. Sure, the routing protocol
attempts to minimize that time period.

This observation leads me to believe (and I welcome discussion on this)
that whatever mechanisms is used for discovery, that if we want a high
level of availability, there is a need for an application layer failover 
mechanism.
This could be a combination of the discovery returning a list of IP addresses
to use, and the ability for the application to redo the discovery.
But solely relying on redoing the discovery will have more delay than
when there are multiple IP addresses known from the start.
Thus I wonder if the architecture here should take into account the need
for such a list of addresses to be provided.

  Erik

--------------------------------------------------------------------
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
--------------------------------------------------------------------