[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/