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

[Alex Zinin <azinin@nexsi.com>]

David,

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

> Not necessarily.  If you have some mechanism that maps between the EID and
> the locator, you can route on the locator independently of the routability
> of the EID.  Numerous mechanisms can be imagined which could provide such a
> mapping service (DNS among them).

Generally yes. In fact, I would even say the routing system should
know nothing about EIDs. This is not they case with Michel's proposal,
though.

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

> My feeling is that any mobility solution that relies on the variability of
> an EID is doomed given current name to address translation technology.  Not
> only do you have to worry about stuff like DNS TTLs, but you must deal with
> the fact that applications themselves cache addresses (that is, application
> data structures know what an address is).

Agree. That's why I think DNS should provide DN->EID mapping where
EID should stay static regardless of the nodes's location/connectivity,
and this is the EID->locator (routing name) mapping that should account
for dynamic changes in it.

> If, however, the EID is separated from the locator, you can vary the locator
> according to topology changes (be they provider driven or the fact you've
> roamed between one cell tower to another) without changing the bucket o'
> bits applications have memcpy'd from the struct hostent returned by
> gethostbyname().

Agreed.

> In this model, DNS TTLs become relevant (assuming the
> locators are looked up via DNS), but that is relatively easy to deal with.

Frankly, I'm having trouble imagining a DNS-based system used to
provide the EID->location mapping dynamic enough and scalable at
the same time to work for mobile nodes. That's another story though...

Alex.