Re: noid and applications (generic requirements from applications)

[Erik Nordmark <Erik.Nordmark@sun.com>]

> What I understood from the noid draft is that what we today call IP 
> addresses (what is above L2, used in the arp requests etc) can be 
> rewritten and because of this doesn't have the properties above.

Perhaps I don't understand what the properties mean, but I don't
see any significant change compared to today.

What noid does it to introduce sets of locators as a new concept,
with the layers under the transport protocols treating the set as a
unit.

When multihoming and there are failures of a path it is true that a single
locator might not be useful; the path to that locator might have failed.
Having the FQDN or the locator set provides the ability to communicate
in the precense of such failures.

Whether the glass is half-full or half-empty in this case is a question of 
perspective. 
Without any multihoming solution today with multiple addresses 
assigned to a host, a single address/locator would fail when there is a
path failure and there is no recourse for the applications/ulp.
Introducing the ability to use a FQDN or locator set provides a mechanism
to repair this.

But if you compare this with introducing a new ID name space (e.g. hashes
of public keys) and a system which securely and efficiently can lookup
such identifiers, then the fqdn+locator set approach is clearly inferior
from the apps perspective. But designing and deploying such a mapping
system would take time and deployment incentives are far from clear. 

The SIM document presents a possible middle ground. It talks about the ability 
to introduce the new name space now, with the hope that the mapping system can
be designed and deployed later. Until the mapping system is in place
applications that wish to do referals need to carry both the ID plus a
snapshow of the locator set (with at least one working locator).

   Erik