Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 21 August 2019 02:51 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1677C12083B for <irtf-discuss@ietfa.amsl.com>; Tue, 20 Aug 2019 19:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbSjTbp4MacE for <irtf-discuss@ietfa.amsl.com>; Tue, 20 Aug 2019 19:51:22 -0700 (PDT)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id EED1B120116 for <irtf-discuss@irtf.org>; Tue, 20 Aug 2019 19:51:20 -0700 (PDT)
Received: (qmail 45576 invoked from network); 21 Aug 2019 02:39:13 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 21 Aug 2019 02:39:13 -0000
To: "ietf@ietf.org" <ietf@ietf.org>, "irtf-discuss@irtf.org" <irtf-discuss@irtf.org>, "6man@ietf.org" <6man@ietf.org>
References: <CAPTMOt+cGhBqHmT3yZVChv-PCMqxT-WPDcDdM3RuTc1TMfFeVg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE148C2FE4@DGGEML532-MBX.china.huawei.com> <10708d7b-a4bc-f9d8-a644-7c5617f5ebf3@gont.com.ar> <CAPTMOtLyiUpi4L+7TpLePvm=JtpEnw-Yv1NCKvO63_HK2jFnCA@mail.gmail.com>
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Message-ID: <447e5dae-2ae9-b9fe-baa2-111c028d3b68@necom830.hpcl.titech.ac.jp>
Date: Wed, 21 Aug 2019 11:51:18 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAPTMOtLyiUpi4L+7TpLePvm=JtpEnw-Yv1NCKvO63_HK2jFnCA@mail.gmail.com>
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/Tf773PqTQUCM_YOdGguGYJkz7pg>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2019 02:51:24 -0000

shyam bandyopadhyay wrote:

> draft-shyam-real-ip-framework

is a reinvention of geography based addressing not acceptable
by ISPs in the real world.

> 2. Separation between Locators and Identifiers. Even though it
> was not documented in the requirement specification of IPv6, growth of
> routing table have become a real problem. One of the source of this
> growth is the way site multihoming has been supported in the existing
> system. Designers spent hell lot of time to come up with solutions like
> ILNP/LISP (with the concept of PI addresses)

LISP is not a solution but yet another garbage.

Attempt to convert ID to locator at the end (using ID as locator)
means loss of reachability to the end results in lack of conversion,
which is not multihoming.

Additional "optimization" to convert ID to locator also in the network
is against the E2E principle needing conversion information, amount
of which is at least proportional to the number of multihomed sites,
in the network, which is no better than having global routing table
entries, number of which is proportional to the number of multihomed
sites.

To make multihoming scale, think end to end, which means both ends
must be involved to make multihoming scale, which is what
draft-ohta-e2e-multihoming-* proposes.

						Masataka Ohta