Re: [rrg] Aggregatable EIDs

wei zhang <zhangwei734@gmail.com> Sat, 26 December 2009 04:42 UTC

Return-Path: <zhangwei734@gmail.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 0E2023A683B for <rrg@core3.amsl.com>; Fri, 25 Dec 2009 20:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.405
X-Spam-Level:
X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45]
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 XFvuhFZf43ql for <rrg@core3.amsl.com>; Fri, 25 Dec 2009 20:42:31 -0800 (PST)
Received: from mail-vw0-f203.google.com (mail-vw0-f203.google.com [209.85.212.203]) by core3.amsl.com (Postfix) with ESMTP id 192273A67A5 for <rrg@irtf.org>; Fri, 25 Dec 2009 20:42:31 -0800 (PST)
Received: by vws41 with SMTP id 41so2572668vws.15 for <rrg@irtf.org>; Fri, 25 Dec 2009 20:42:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=f22CcUQDORDoeKwD3n24Fnbgs83HXjrzDrmIEqy8WRQ=; b=dacwdrs51NXgHeOYJjy/i10lA0EcKUqDjxyPHRJIcoZyuDbPm0DOuiBQiYFMTMFVv8 OX+KGXg+OsW4hVmYODdVQva54ix/FpahZv08OEaWfLVvLJ2fQ7EYUzWf9i3Js/qzEZGH MqBPX5d6KYmHnskoR7swlvMaSzOOM+S0CgcZE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=g6H0n5Ky3udu2wA6Cfg3uE7vRl5dt/uop/RgAtpFr1iFhwGhaImHXQzOPEKry7kYO9 pPTM9KEkdYjg7aCk5eaAAwaVkibeqIlxHPs3aE4D86c7I8NsfAAgY+Lg34EyV30T3duG ZTGdwnOEdfy3PIAZi3S/f92eCXbew5EzYkxmE=
MIME-Version: 1.0
Received: by 10.220.125.106 with SMTP id x42mr9882886vcr.44.1261802532040; Fri, 25 Dec 2009 20:42:12 -0800 (PST)
In-Reply-To: <000901ca85c9$a077b1c0$c30c6f0a@china.huawei.com>
References: <4B351345.7080908@gmail.com> <000901ca85c9$a077b1c0$c30c6f0a@china.huawei.com>
Date: Sat, 26 Dec 2009 12:42:11 +0800
Message-ID: <a3c6b13a0912252042vf418e37s85f3f8731a50c0f4@mail.gmail.com>
From: wei zhang <zhangwei734@gmail.com>
To: Xu Xiaohu <xuxh@huawei.com>, brian.e.carpenter@gmail.com
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: quoted-printable
Cc: rrg@irtf.org
Subject: Re: [rrg] Aggregatable EIDs
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: Sat, 26 Dec 2009 04:42:32 -0000

Hi, Brian and Xiaohu

My response to your comments inline.

2009/12/26 Xu Xiaohu <xuxh@huawei.com>:
>
>
>> -----邮件原件-----
>> 发件人: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] 代表 Brian E
>> Carpenter
>> 发送时间: 2009年12月26日 3:32
>> 收件人: wei zhang
>> 抄送: rrg@irtf.org
>> 主题: [rrg] Aggregatable EIDs
>>
>> On 2009-12-26 05:52, wei zhang wrote:
>> ...
>> > A good answer is that the EID should also be aggregateable,
>>
>> I may be missing what you mean, because it seems to me that
>> any set of bit strings (even of variable length) is aggregatable
>> to an arbitrary extent. Just build a binary tree and chop it
>> off at whatever level you want (/N if you want 2^N aggregates).
>
Here the EID aggregation is based on the same mapping information,
e.g. if 2 neighboring /16 EIDs map to different RLocs, there needs at
least 2 entries in the mapping system for this discrimination.
Therefore they are not "aggregateable"  if concerned by scalable
mapping.

> Agree. Even the EID is a flat label, the corresponding ID->Locator mapping
> system could scale well by using some methods, e.g., DHT.
>
DHT also builds fine hierarchies within its scheme, or to say a flat
label can be organized in a logic hierarchical structure. Indeed
hierarchical structure helps to alleviate scalability problems, but it
might be prudent to say it scales "better" (than flat label) instead
of "well" if we are facing an already massive mess. IMHO, to make EID
organized/assigned in an "aggregateable" way beforehand can be easier
than to find any aftermath remedies.

> IMO, a major reason that the EID should be hierarchical is as follows:
>
> The resolution infrastructure for flat names has no "pay-for-your-own”
> model, as the flat names are stored at essentially random nodes. In
> contrast, the resolution infrastructure for the hierarchical host
> identifiers has reasonable business models and clear trust boundaries. Since
> the hierarchical host identifiers have clear organization affiliation, the
> identifier resources and the corresponding mappings can be managed by
> different bodies with clear administrative boundaries.
>
I agree. Hierarchically organized EID with some constraints on its
assignment(clear organization affiliation) guarantees scalable
mapping, since theoretically the information entropy reduced.
However, before anyone enforces these constraints in the Internet, we
need to define the hierarchy with corresponding range of effects which
is my intention of designing "aggregateable" EID on behalf of ID/Loc
mapping scalability.

Wei Zhang