Re: [rrg] rrg Digest, Vol 15, Issue 44

wei zhang <zhangwei734@gmail.com> Fri, 25 December 2009 16:53 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 5E1643A6831 for <rrg@core3.amsl.com>; Fri, 25 Dec 2009 08:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599]
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 gh+xP7uYx8C1 for <rrg@core3.amsl.com>; Fri, 25 Dec 2009 08:53:08 -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 305353A67BE for <rrg@irtf.org>; Fri, 25 Dec 2009 08:53:08 -0800 (PST)
Received: by vws41 with SMTP id 41so2513945vws.15 for <rrg@irtf.org>; Fri, 25 Dec 2009 08:52:50 -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:content-type :content-transfer-encoding; bh=QcXjah6juL+NlJav85mA4sJB/qRdKa1orVR23ubwz7o=; b=iqpVnd9A5NEDc/WFtQKR/LGGrAB4BU0WJ8vBS1nohrTbvbi2/0sL+hVt0by9f0d2jN U6mLULWUiPQk/zbsW15VT925InWMWIrTAoSkCOQs9tOgvL0zs7FBShQ5in8x2kt/noHX J/iMkFOnqkTMGVm9osuDQ5NubKCUxrECwtKoY=
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 :content-type:content-transfer-encoding; b=thefJt2lsnx+NqBBKl09zLe0oz46wCxPRZOksWzaq0nEwYcfEmESyiZj9NLLkIjMe4 XlnhJmzVj+jh2IQr2rP2Dv514iw86Eh5U2nJxGHEe7PJ465JjWF4eyV/BDEL6RaOTiZ9 n2QvvuV8f5jwAGrqbLdGENoivgJXXfM5L5Gtc=
MIME-Version: 1.0
Received: by 10.220.122.73 with SMTP id k9mr13767320vcr.84.1261759969871; Fri, 25 Dec 2009 08:52:49 -0800 (PST)
In-Reply-To: <mailman.6320.1261671743.32729.rrg@irtf.org>
References: <mailman.6320.1261671743.32729.rrg@irtf.org>
Date: Sat, 26 Dec 2009 00:52:49 +0800
Message-ID: <a3c6b13a0912250852g2467e97jda909fe2bf8202d6@mail.gmail.com>
From: wei zhang <zhangwei734@gmail.com>
To: rrg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rrg] rrg Digest, Vol 15, Issue 44
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: Fri, 25 Dec 2009 16:53:09 -0000

> On Dec 17, 2009, at 1:02 AM, Flinck, Hannu (NSN - FI/Espoo) wrote:
>
>> Most of the scalability discussions we have had are dealing exactly
>> with
>> the mapping system, not how to tunnel or rewrite the addresses. The
>> mapping system is the architecture that uses the tunnels or address
>> manipulation based on some address structure.  A tunneling
>> scheme/address rewrite together with an address structure is not
>> sufficient for scalabilty.
>>
>> - Hannu

> Hi Hannu,
>
> I agree that the mapping itself is a critical part of the
> architecture. However I believe a mapping proposal needs to go
> together with an overall architecture, because one needs to know where
> mapping happens, mapping what to what.
> Take a simple example: ILNP has kind of mapping (implemented in DNS)
> and LISP has another kind of mapping, 2 different proposals have
> rather different mappings.
>
> Lixia
>
>> -----Original Message-----
>>> From: rrg-bounces@irtf.org [mailto:rrg-bounces@irtf.org] On
>>> Behalf Of ext Tony Li
>>> Sent: Tuesday, December 15, 2009 11:52
>>> To: Brian E Carpenter
>>> Cc: rrg@irtf.org; Lixia Zhang
>>> Subject: Re: [rrg] belated msg: further description of the
>>> recommendation process
>>>
>>> Brian E Carpenter wrote:
>>>
>>>>> Mapping systems are obviously a component of a solution but are not
>>>>> by themselves a solution.  To be considered seriously, they
>>> should be
>>>>> used in conjunction with some network layer solution.
>>>>
>>>> Hmm. Don't you think that to some extent these should be orthogonal?
>>>> A mapping mechanism needs to meet the specific requirements of a
>>>> network layer mechanism, but that doesn't require the two to be
>>>> irrevocably bound to each other.
>>>>
>>>> I have a feeling that the mapping system should be very general in
>>>> nature, in case the first cut at either the locator or identifier
>>>> space proves to fall short. Also I feel it should support hierarchy,
>>>> even if we don't need a hierarchy from the start.
>>>
>>> Brian,
>>>
>>> Our recommendation is focused on providing an alternative
>>> routing architecture.  A mapping system is a fine component,
>>> but would not seem to provide a credible architecture by itself.
>>>
>>> Tony
>>>
>>> _______________________________________________
>>> rrg mailing list
>>> rrg@irtf.org
>>> http://www.irtf.org/mailman/listinfo/rrg
>>>
>

Hi, all

It seems to me the logic is inside the routing architecture. A
scalable routing architecture intrinsicly requires properly designed
routing hierarchy with topology sensitive aggregateable address
(RLoc/PA addr. or sth like that). On the other hand, the upper layer
over IP requires a fixed interface with layer 3 which is not topology
sensitive and globally unique(EID/Host ID). This contradictory
requirements partly incurred ID/Loc seperation and inevitably a
mapping between them. If we introduce this kind of Locator and ID into
the routing scheme, the routing with the aggregateable hierarchy can
be scalable for sure, but the mapping scalability may not be
guaranteed or even worse, inefficient for another lookup besides
routing. As a consequence, we shift the routing scalability problem to
the mapping scalability problem.

Therefore many proposals focus their artifice on mapping mechanisms to
find a final solution for the scalability problem.To make the mapping
system scalable becomes the ultimate resort to settle this issue down.
However many efforts dispersed our attention on overheads,
security(e.g. LISP NERD) or performance (e.g. data probe in LISP ALT )
etc. We should attack the core directly and make the mapping system
scalable before we deduce a perfect mapping mechanism.

A good answer is that the EID should also be aggregateable, but the
aggregation is independent of routing topology. EID aggregation can be
implemented in many ways (even virtually or conceptually). Anyway we
need a corse EID granularity in the mapping scheme.

If we put these pieces together, a hierarchically organized RLoc and a
corse EID aggregation are prerequisites of a scalable mapping and
routing. Under such circumstances, the number of entries in the
mapping system will admirably scale with Internet size.

I agree the mapping scheme must be imbedding in a certain routing
architecture, just like addressing scheme in a routing mechanism.
However the EID aggregation design can be relatively independent and
be treated as a general design. Later on, how to deploy and implement
mapping system will be either illustrated on the core/edge split
(with tunnel or rewrite) abstraction or with other new designs.

As a summary, towards the scalable Internet routing architecture, the
route map can be like this: design a routing hierarchy with
aggregateable Locator, design ideal EID aggregation to facilitate
scalable mapping, design efficent mapping scheme with specific
forwarding mechanism, at last polish all designs with various
operational requirements.

Merry Christmas!

Wei Zhang