[rrg] Rebuttal for RANGI//re: Reminder
Hi Tony and Lixia, The rebuttal for RANGI is as follows: The reason why the ID->Locator lookup is separated from the FQDN->ID lookup is: 1) not all applications are tied to FQDNs, and 2) it seems not necessary to require all devices to possess a FQDN of their own. Basically RANGI uses DNS to realize the ID->Locator mapping system. If there are too many entries to be maintained by the authoritative servers of a given Administrative Domain (AD), Distribute Hash Table (DHT) technology can be used to make these authoritative servers scale better, e.g., the mappings maintained by a given AD will be distributed among a group of authoritative servers in a DHT fashion. As a result, the robustness feature of DHT is inherited naturally into the ID->Locator mapping system. Meanwhile, there is no trust issue since each AD authority runs its own DHT ring which maintains only its presidial mappings. For host mobility, if communicating entities are RANGI nodes, the mobile node will notice the correspondence node of its new locator once its locator changes due to a mobility or re-homing event. Meanwhile, it should also update its locator information in the ID->Locator mapping system timely by using the Secure DNS Dynamic Update mechanism defined in [RFC3007]. In case of simultaneous mobility, at least one of them has to resort to the ID->Locator mapping system for resolving the correspondence node’s new locator so as to continue their communication. If the correspondence node is a legacy host, Transit Proxies, which play the similar function as the home-agents in Mobile IP, will relay the packets between the communicating parties. RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with both legacy IPv6 and IPv4 sites. Since proxies function as RANGI hosts, they can handle Locator Update Notification messages sent from remote RANGI hosts (or even from remote RANGI proxies) correctly. Hence there is no edge-to-edge aliveness problem. Details will be specified in the latter version of RANGI-PROXY. The intention that RANGI uses IPv4-embeded IPv6 addresses as locators is to reduce the total deployment cost of this new Internet architecture and to avoid renumbering the site internal routers when such a site changes ISPs. Best wishes, Xiaohu 发件人: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] 代表 Tony Li 发送时间: 2010年2月11日 5:37 收件人: 'RRG' 主题: Re: [rrg] Reminder Hi folks, Remember this? I’ve seen one submission. Are folks working on things? Tony Hi all, We've had a bit of a schedule slip. We are still trying to hit a final document date of Mar. 8. That gives us just less than 7 weeks. The next deadline for a rebuttal is Feb. 9. The deadline for counterpoints will then be Mar. 2. This will give us a few days for final document prep. The word count limit for the rebuttal is 500 words. Regards, Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Rebuttal for RANGI//re: Reminder
Hi all, I have updated the RANGI draft to -03 version. Any comment is welcomed. Hi Tony, would you please update the RANGI reference in the recommendation draft? Best wishes, Xiaohu > -邮件原件- > 发件人: Xu Xiaohu [mailto:x...@huawei.com] > 发送时间: 2010年2月11日 16:14 > 收件人: 'Tony Li'; 'Lixia Zhang' > 抄送: 'RRG' > 主题: Rebuttal for RANGI//re: [rrg] Reminder > > Hi Tony and Lixia, > > The rebuttal for RANGI is as follows: > > The reason why the ID->Locator lookup is separated from the FQDN->ID lookup > is: 1) not all applications are tied to FQDNs, and 2) it seems not necessary > to require all devices to possess a FQDN of their own. Basically RANGI uses > DNS to realize the ID->Locator mapping system. If there are too many entries > to be maintained by the authoritative servers of a given Administrative Domain > (AD), Distribute Hash Table (DHT) technology can be used to make these > authoritative servers scale better, e.g., the mappings maintained by a given > AD will be distributed among a group of authoritative servers in a DHT > fashion. > As a result, the robustness feature of DHT is inherited naturally into the > ID->Locator mapping system. Meanwhile, there is no trust issue since each AD > authority runs its own DHT ring which maintains only its presidial mappings. > > For host mobility, if communicating entities are RANGI nodes, the mobile node > will notice the correspondence node of its new locator once its locator > changes > due to a mobility or re-homing event. Meanwhile, it should also update its > locator information in the ID->Locator mapping system timely by using the > Secure DNS Dynamic Update mechanism defined in [RFC3007]. In case of > simultaneous mobility, at least one of them has to resort to the ID->Locator > mapping system for resolving the correspondence node’s new locator so as to > continue their communication. If the correspondence node is a legacy host, > Transit Proxies, which play the similar function as the home-agents in Mobile > IP, will relay the packets between the communicating parties. > > RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with both > legacy > IPv6 and IPv4 sites. Since proxies function as RANGI hosts, they can handle > Locator Update Notification messages sent from remote RANGI hosts (or even > from > remote RANGI proxies) correctly. Hence there is no edge-to-edge aliveness > problem. Details will be specified in the latter version of RANGI-PROXY. > > The intention that RANGI uses IPv4-embeded IPv6 addresses as locators is to > reduce the total deployment cost of this new Internet architecture and to > avoid > renumbering the site internal routers when such a site changes ISPs. > > Best wishes, > Xiaohu > > 发件人: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] 代表 Tony Li > 发送时间: 2010年2月11日 5:37 > 收件人: 'RRG' > 主题: Re: [rrg] Reminder > > > Hi folks, > > Remember this? I’ve seen one submission. Are folks working on things? > > Tony > > > Hi all, > > We've had a bit of a schedule slip. We are still trying to hit a final > document > date of Mar. 8. That gives us just less than 7 weeks. The next deadline for > a rebuttal is Feb. 9. The deadline for counterpoints will then be Mar. 2. This > will give us a few days for final document prep. > > The word count limit for the rebuttal is 500 words. > > Regards, > Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Rebuttal for RANGI//re: Reminder
On 2/11/10 12:14 AM, "Xu Xiaohu" wrote: > The rebuttal for RANGI is as follows: Received and incorporated. Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
Re: [rrg] Rebuttal for RANGI//re: Reminder
On 2/12/10 2:09 AM, "Xu Xiaohu" wrote: > I have updated the RANGI draft to -03 version. Any comment is welcomed. > > Hi Tony, would you please update the RANGI reference in the recommendation > draft? Thanks to the miracles of XML2RFC, draft updates are automatically incorporated, so this will be visible in the next version. Tony ___ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg