[rrg] "Overloading" of Loc & ID functions is good for hosts and should be maintained
Robin Whittle <rw@firstpr.com.au> Tue, 22 June 2010 11:57 UTC
Return-Path: <rw@firstpr.com.au>
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 E74053A69B8 for <rrg@core3.amsl.com>; Tue, 22 Jun 2010 04:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.705
X-Spam-Level:
X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
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 MjjKs9DOH7UY for <rrg@core3.amsl.com>; Tue, 22 Jun 2010 04:57:14 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 5E0BF3A68F0 for <rrg@irtf.org>; Tue, 22 Jun 2010 04:57:14 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 32BE1175F39; Tue, 22 Jun 2010 21:57:19 +1000 (EST)
Message-ID: <4C20A51F.302@firstpr.com.au>
Date: Tue, 22 Jun 2010 21:57:19 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <48462EB0-FF98-4933-9C7A-1B7B4E29EFBF@gmail.com> <22CFC96B-70FA-45BD-A3F2-B1E99B6E5B5D@gmail.com> <AANLkTinVeqBZkECcdBqkhglLgUj7euPoCyL0MOYxrxfx@mail.gmail.com> <E06B9C69-7151-4CD5-9627-3F86153FED4D@gmail.com>
In-Reply-To: <E06B9C69-7151-4CD5-9627-3F86153FED4D@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: RJ Atkinson <rja.lists@gmail.com>
Subject: [rrg] "Overloading" of Loc & ID functions is good for hosts and should be maintained
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: Tue, 22 Jun 2010 11:57:16 -0000
Hi Ran, You wrote (msg06884), in part: > If we ignore the lack of 40 years since the initial definition > of IP itself, I believe there is actually pretty broad consensus, > both within this RG, and also within the routing/addressing parts > of the IETF, that the current overloaded semantics are indeed > the root of multiple problems. These are problems for today's interdomain routing system, in that it causes scaling problems with the growth in the number of PI prefixes, and the rate of change in how they are advertised in the DFZ. However, "overloading" - having the IP address perform the roles of Identifier and Locator - is good for hosts. As long as hosts can rely on the routing system (local systems plus interdomain routing system) behaving as they do today, then hosts are saved a great deal of effort. In today's "overloaded" system, when a host emits a packet with destination address NNNN, the routing system will: 1 - Generally deliver the packet to the one host whose IP address is NNNN, or to one of the hosts with this address if there are multiple such hosts (anycasting). Otherwise, the packet will be dropped somewhere. 2 - Will not deliver the packet to any host which does not have the IP address NNNN and therefore is not a host which is the intended destination of the packet. So the sending host doesn't concern itself with where the destination host is (or where the closest one of multiple anycasts hosts is). Nor does it need to concern itself with the possibility that the packet will be delivered to some host whose identity does not match the destination address. Compared to a Core Edge Elimination = Locator / Identifier Separation architecture such as ILNP, the current "overloaded" system puts a lot of responsibility on the routing system and takes it off the hosts. Loc/ID Separation architectures (LISP is not such an architecture) solve the scaling problem by forcing all hosts to manage separate Identifiers and Locators, and for packets to contain these two separate things, for both destination and source addresses. This makes things quite easy for the routing system, so solving the routing scaling problem. I believe the existing division of responsibilities is good and should be maintained. If Loc/ID Separation was adopted, hosts would need to do mapping lookups and other complex, delay-prone, operations before they can send packets to a new destination. This will generally delay the establishment of communications, since these lookups must be done by the hosts. LISP, Ivip and IRON are Core Edge Separation architectures which preserve the current "overloaded" nature of the the IP address. I think this is a good thing: make the routing system somewhat more complex so it can support hosts in their current, relatively simple, form. This will be faster (in terms of establishing initial communications, at least with Ivip and perhaps IRON) and more efficient (hosts not having to send and receive longer packets, or more packets) than with any Loc/ID Separation architecture such as ILNP. It will also more efficient in terms of hosts not needing to maintain any extra state or fuss around with things which the routing system currently handles: how to get a packet to a host whose identity is NNNN. Since more and more hosts are going to be battery operated devices running from potentially slow, high latency, wireless connections, it is all the more important that we not try to change the architecture to something like Loc/ID Separation, which further burdens these links and hosts. For my overview of what I think should happen: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html but IRON-RANGER has changed a lot since then. I plan to write about it soon. - Robin http://www.firstpr.com.au/ip/ivip/
- [rrg] Terminology straw poll RJ Atkinson
- Re: [rrg] Terminology straw poll Toni Stoev
- Re: [rrg] Terminology straw poll Fred Baker
- Re: [rrg] Terminology straw poll Noel Chiappa
- Re: [rrg] Terminology straw poll Steven Blake
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll – participant id… Toni Stoev
- Re: [rrg] Terminology straw poll Scott Brim
- Re: [rrg] semantic overloading RJ Atkinson
- Re: [rrg] Terminology straw poll – participant id… Dae Young KIM
- Re: [rrg] Terminology straw poll Stephen D. Strowes
- Re: [rrg] semantic overloading Dae Young KIM
- Re: [rrg] Terminology straw poll Scott Brim
- Re: [rrg] Terminology straw poll Paul Jakma
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Fred Baker
- Re: [rrg] semantic overloading t.petch
- Re: [rrg] Terminology straw poll Noel Chiappa
- Re: [rrg] Terminology straw poll William Herrin
- Re: [rrg] Terminology straw poll Paul Jakma
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Chris Grundemann
- Re: [rrg] Terminology straw poll Fred Baker
- Re: [rrg] Terminology straw poll William Herrin
- Re: [rrg] Terminology straw poll – participant id… Fred Baker
- Re: [rrg] Terminology straw poll Fred Baker
- Re: [rrg] Terminology straw poll Noel Chiappa
- [rrg] Forwarding/non-forwarding node functional s… Toni Stoev
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Noel Chiappa
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll – participant id… Dae Young KIM
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll William Herrin
- Re: [rrg] Terminology straw poll Tony Li
- Re: [rrg] Terminology straw poll William Herrin
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Tony Li
- Re: [rrg] Terminology straw poll William Herrin
- Re: [rrg] Terminology straw poll Dae Young KIM
- Re: [rrg] Terminology straw poll Tony Li
- Re: [rrg] Terminology straw poll Noel Chiappa
- Re: [rrg] Terminology straw poll heinerhummel
- Re: [rrg] Terminology straw poll heinerhummel
- Re: [rrg] Terminology straw poll heinerhummel
- Re: [rrg] Terminology straw poll Paul Jakma
- Re: [rrg] Terminology straw poll Paul Jakma
- Re: [rrg] Terminology straw poll Noel Chiappa
- Re: [rrg] Terminology straw poll heinerhummel
- Re: [rrg] Terminology straw poll Tony Li
- [rrg] "Overloading" of Loc & ID functions is good… Robin Whittle
- Re: [rrg] "Overloading" of Loc & ID functions – A… Toni Stoev
- [rrg] Toni Stoev's proposal for Loc/ID separation Robin Whittle
- Re: [rrg] Toni Stoev's proposal for Loc/ID separa… Toni Stoev
- Re: [rrg] Toni Stoev's proposal for Loc/ID separa… Robin Whittle
- Re: [rrg] Toni Stoev's proposal for Loc/ID separa… Toni Stoev
- Re: [rrg] Toni Stoev's proposal for Loc/ID separa… Robin Whittle
- Re: [rrg] Toni Stoev's proposal for Loc/ID separa… Toni Stoev
- Re: [rrg] Terminology straw poll Marshall Eubanks
- Re: [rrg] Terminology straw poll Tony Li