[rrg] Rebuttal for RANGI//re: Reminder

Xu Xiaohu <xuxh@huawei.com> Thu, 11 February 2010 08:13 UTC

Return-Path: <xuxh@huawei.com>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6293A73F1 for <rrg@core3.amsl.com>; Thu, 11 Feb 2010 00:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.61
X-Spam-Level:
X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW+9MW6-bJfJ for <rrg@core3.amsl.com>; Thu, 11 Feb 2010 00:13:23 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6A5DA3A6FF9 for <rrg@irtf.org>; Thu, 11 Feb 2010 00:13:23 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXO00FGP4802F@szxga04-in.huawei.com> for rrg@irtf.org; Thu, 11 Feb 2010 16:14:24 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KXO002O0480JX@szxga04-in.huawei.com> for rrg@irtf.org; Thu, 11 Feb 2010 16:14:24 +0800 (CST)
Received: from HUAWEIE75F8F11 ([10.111.13.9]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KXO00ION47ZV9@szxml04-in.huawei.com> for rrg@irtf.org; Thu, 11 Feb 2010 16:14:24 +0800 (CST)
Date: Thu, 11 Feb 2010 16:14:23 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <C79866E6.1DA3%tony.li@tony.li>
To: 'Tony Li' <tony.li@tony.li>, 'Lixia Zhang' <lixia@cs.ucla.edu>
Message-id: <004601caaaf2$389be9b0$090d6f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: quoted-printable
Thread-index: AcqqmSAsFLBw3Qk+jEiq/IlI/4yR/wAVlhQg
Cc: 'RRG' <rrg@irtf.org>
Subject: [rrg] Rebuttal for RANGI//re: Reminder
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2010 08:13:24 -0000

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-bounces@irtf.org [mailto:rrg-bounces@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