On Feb 22, 2008, at 8:16 AM, Noel Chiappa wrote:
From: Randall Atkinson <rja@extremenetworks.com>The overwhelming majority of users/deployments today are unable to distinguish "DNS service unavailable" from "network down". ... I think this means that being more explicitly reliant on DNS service availability now, versus 20 years ago, is widely acceptable.True, and a good point, but... We do need to distingiush between "a member of the set of things required to be operational in order for normal users to beable to do stuff" and "a dependency loop which could prevent networkengineering personnel from repairing a fault" - the latter set should beempty!
It may be that DNS itself (at least, the human readable part) becomes less important to end users in the future. The point of indirection between namespaces, and the corresponding lookup service, is no doubt useful. However, there seems to be new human-friendly names emerging that end users prefer over direct DNS interaction (e.g. links in search engine results, bookmarks in browsers, etc). These names may or may not bypass DNS. Perhaps in the future folks will be unable to distinguish between "network down" and "favorite web portal down" - especially if most of their services are part of said portal. Or maybe something like "skype works, but i can't get my mail".
Given this, how are we scoping the "routing" part of the problem? Or perhaps, what is the nature of the service provided by the routing system (where failure of this service defines a fault)? For example, given a sender knows of "some" name for the destination, and there exists a viable hop-by-hop router path between these endpoints, is it acceptable for delivery of packets along that path to depend on a box/ service that is off-path and perhaps unreachable? If the delivery requires mapping one name to another, must this mapping mechanism reside along the path (i.e. basically become part of the routing system)? If so, this would seem to make it easier to compare the complexity of different routing approaches. Otherwise, the service provided by the various approaches is probably different.
R, Dow -- to unsubscribe send a message to rrg-request@psg.com 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