_____ Presumably if you move to another network, you'll need to get another identifier. One could imagine that this could be based on DHCP, or by manual configuration. Isn't this what we are trying to avoid? If I move my site to another provider my locators change right? If they do change, can't my IDs collide with someone else's ones? Nope. Changing locators when you move is entirely expected and required. Yes, your ID's could collide, which is why you might need to get new ones. Note that if a network uses particular ID allocation policies (e.g., your MAC address is your identifier), this is very unlikely. Well, the ID identifies the host not the interface in this proposal, it says something about generating the ID with your set of MACs, if you do this or even if you random choose it a collision is very unlikely I agree, but the possibility exists. Agreed. In which case, you do a manual identifier assignment. ----- Is this proposal suggesting that DNS should be responsible for finding the hosts locators? Is a DNS update fast enough for that to work (i.e. with mobility) or cached entries make it too slow? DNS is only responsible for the mapping function from FQDN to a set of locators. I read you get two things from DNS: "L" and "I" records. I assume those are Locators and Identifiers (I don't understand why ID's in plural). My doubt is: is DNS fast enough for solving this? To move a site to a new provider what do I have to do? How long are invalid locators (new site to where I still didn't move or old site after moving) in some DNS server's cache and what is the impact of that? Multiple identifiers are an entirely logical result of the situation that you posited above: the host moves and gets a new ID. DNS is fast enough for long term moves, but is not fast enough for mobility. Neither is any other mapping system in any solution proposed to date. If a host moves to a site, it needs to learn its new locators and then advertise them through DNS (or it's clone). Old entries in DNS will cause connectivity faults. Note that this is again the same, regardless of the mapping function. In previous discussions, I believe that we came to the consensus that RRG is not trying to solve the full-blown mobility problem. The rate of dynamism is higher than what we'd really like to support in any mapping function. Well, I'm new around here, I'll take that into account, thanks. But the draft says that ILNP treats mobility as a special case of multihoming and solves it. Clearly, it can't solve arbitrarily high speed mobility. What it can do is to avoid the triangle routing problem. Tony
_______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
