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

[Alex Zinin <azinin@nexsi.com>]

Michel,

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

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

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

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

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.