Subject: Re: question about draft-irtf-nsrg-report-09.txt

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 24 Apr 2003 12:29:09 -0400

> From: Keith Moore <[email-masked]>

    > you immediately need to build a reliable system to map between the
    > two - where reliable means: fast, up-to-date, highly available,
    > provides repeatable results across the entire network.

Many people keep claiming this, but I've yet to see the case clearly laid
out as to why. Let me explain.

If you start with a design which basically replicates the capabilities of
the system we have today, you arrange it so that whatever transaction (in
the loose sense) that provided you with the IPvn address instead provides
you with the locator/identifier pair. So, if you did a DNS lookup, that
would give you back both; if you're a server and someone opens a
connection to you, that ICP packed would give you both.

Well, that's not a very interesting system, because it just replicates the
capabilities of the system we already have. To make it useful/interesting,
you want to be able to change the binding between the two.

Well, for many cases of current interest, you can in fact do that without
having a mapping system available. E.g. for multi-homing (done with
multiple addresses), at ICP time the multi-homed entity provides all of
its addresses. Etc, etc - I won't go into all the details now.

I'm *not* saying that I'm *sure* we *never* have need of such a mapping
system; I'm just saying that I don't think anyone has sat down and really
tried to work through the details and see how far you can get without one.

	Noel

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 Apr 2003 15:13:33 -0400

>     > you immediately need to build a reliable system to map between
>     > the two - where reliable means: fast, up-to-date, highly
>     > available, provides repeatable results across the entire
>     > network.
> 
> Many people keep claiming this, but I've yet to see the case clearly
> laid out as to why. Let me explain.
> 
> If you start with a design which basically replicates the capabilities
> of the system we have today, you arrange it so that whatever
> transaction (in the loose sense) that provided you with the IPvn
> address instead provides you with the locator/identifier pair.

this really only works if the transaction is repeatable (with all of the
usual caveats about precision, reliability, efficiency, and consistency)
by any of the peers that might get the locator/identifier pair, and
might need a different locator (or a change to a locator) at some point.

and this tends to mean that you want to sepearate the step that gets
you the precise endpoint identifier from the step that gets you
locators.  of course, if you get an initial set of locators along with
the identifier, this is a useful optimization, but it doesn't mean you
can dispense with the capability to do an identifier->locator mapping in
the future.

> Well, that's not a very interesting system, because it just replicates
> the capabilities of the system we already have. To make it
> useful/interesting, you want to be able to change the binding between
> the two.
> 
> Well, for many cases of current interest, you can in fact do that
> without having a mapping system available. E.g. for multi-homing (done
> with multiple addresses), at ICP time the multi-homed entity provides
> all of its addresses. Etc, etc - I won't go into all the details now.

this works just fine if all of the addresses always work.  it's when one
of the addresses fails to work that it causes problems, especially when
you can't tell whether the addresses returned in response to a
subsequent query really refers to the same host you were talking to, or
just a different host that provided the same service. 

Keith