IETF Logo Mail Archive

Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp)

jnc@mercury.lcs.mit.edu (Noel Chiappa) Wed, 18 March 2009 15:43 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: lisp@core3.amsl.com
Delivered-To: lisp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F9D33A6837; Wed, 18 Mar 2009 08:43:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.421
X-Spam-Level:
X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 MAZH2vDZ5jCX; Wed, 18 Mar 2009 08:43:14 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 7F40F3A6403; Wed, 18 Mar 2009 08:43:14 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F15446BE578; Wed, 18 Mar 2009 11:43:56 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20090318154356.F15446BE578@mercury.lcs.mit.edu>
Date: Wed, 18 Mar 2009 11:43:56 -0400
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] WG Review: Locator/ID Separation Protocol (lisp)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2009 15:43:15 -0000

    > From: Sam Hartman <hartmans-ietf@mit.edu>

    > EIDs have local topology and are locally routable. They contain three
    > portions: a part that identifies an organization. That part really does
    > seem to be an identifier. They contain a portion that identifies a
    > subnet within an organization and a portion that identifies an
    > interface.

It's probably worth also noting (in addition to the caveats about the
semantics changing over time) that "organization" != "portion of network".
I.e. a chunk of namespace might be allocated to an organization, but it might
further subdivide that chunk, and allocate one part to an office in one
location, and another part to an office elsewhere.

In general, the Internet has a long history of taking layers of binding and
using them in, ah, 'creative' ways. Look at ARP and ARP subnetting, and DNS
and load sharing, etc, etc. So no doubt the layer of binding available here
will also be utilized in 'creative' ways we don't currently visualize.

	Noel

v2.23.0 | Report a Bug | By Email