Subject: RE: Missing DNS reqt? [was Re: (multi6) requirements draft comments]

From: "Michel Py" <[email-masked]>
Date: Wed, 2 Jan 2002 19:41:01 -0800

Alex,

>> Michel Py Wrote:
>> It does not need to be a centralized directory. If the endpoint "name"
>> is addressable (I do not like "name" in this context as it implies
>> DNS but I will keep it for consitency) the endpoint itself can answer
>> queries about its own locations <== (more than one).
>> In the concept I propose, what you call name is a PI address, and
>> its locations are several PA addresses. The key is to make the name
>> itself addressable.
> Alex Zinin wrote:
> If you make EID (your PI address) "addressable" and expect it to be
> usable by the endpoint to tell its routing names, then EID needs to
> be routable (and assumably under any possible connectivity scenarios),

Yes. If it is addressable it needs to be routable and routed. And, in the
case of Tony's geo PI, it also needs to be aggregated.

> hence we seem to end up with the same problem---the routing system
> has to handle non-connectivity-based addresses.

I am not sure I fully understand what you mean here. I would not call
a PI address a non-connecticity-based address.

> My understanding is that separating routing names from EIDs makes
> sense if the routing system does not need to know anything about EIDs.

Although I agree, I think that this topic would be better
addressed by looking at the specifics of each solution.
For my model, I think that it would be appropriate to say:
resolve(name) = EID = PI address
locations = PA addresses

> Regarding the question of whether EID->routing name mapping
> should be done through DNS together with DN->EID mapping or
> through a separate packet exchange.

This is why it is a good idea for each solution to precisely
describe the impact it has on DNS, so we can evaluate if it
could possibly fly with DNS or needs son-of-DNS.

> I think it is important
> to keep in mind node mobility, where the node's routing name
> changes dynamically. The relatively static nature of [at least]
> today DNS does not converge well with possible dynamics of the
> routing name.

That is quite another story. The title of this working group is:
"Site Multihoming in IPv6" which implies that a site is not moving
too often. This would be better answered by the chairs, but I
personally think that multihoming for mobile IPv6 is out of scope
here. Not that we don't like it, but we have a big enough problem.

Michel.

---

From: David Conrad <[email-masked]>
Date: Wed, 02 Jan 2002 20:56:34 -0800

Hi,

On 1/2/02 7:41 PM, "Michel Py" <[email-masked]> wrote:
> The title of this working group is:
> too often. 

I didn't see that implication.

> This would be better answered by the chairs, but I
> here.

While I tend to agree that it is out of scope for the working group, I
personally see multi-homing, mobility, and renumbering as facets of the same
problem, namely the use of the end point identifier as the routing locator.
A solution that addresses (pun intended) the multi-homing requirement may
also address the mobility/renumbering problem.

Rgds,
-drc

---

From: Alex Zinin <[email-masked]>
Date: Thu, 3 Jan 2002 00:20:39 -0800

Michel,

> a PI address a non-connecticity-based address.

My bad. The term was induced by some next gen addr/rtg architecture
ideas, much in line with Noel's where the addresses are derived
from the routing structure. PA would then be connectivity-based,
while PI would not.

To ensure efficient abbreviation of reachability information as
it is distributed through a routing system, it is important to
minimize (ideally eliminate) non-connectivity based information.
Splitting the routing name and EID notions (routing and transport
names) allows the routing system to bother with connectivity-based
addresses only. Requiring EIDs to be routable essentially defeats
the purpose of split---the same old problem is applicable to
EIDs now.

> resolve(name) = EID = PI address

Still, in your case PIs need to be routable and routable
through multiple SPs...

> here. Not that we don't like it, but we have a big enough problem.

Whether this is within the WG charter or not, as well as whether
we like it or not, mobility is essentially a very dynamic case
of multihoming. I would hate seeing us producing an architecture
for any of them that would ignore the presence of the other.

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 3 Jan 2002 00:33:51 -0800

> also address the mobility/renumbering problem.

Agree completely.

Alex.