IETF Logo Mail Archive

Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces

Sam Hartman <hartmans-ietf@mit.edu> Fri, 20 March 2009 14:41 UTC

Return-Path: <hartmans@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 BF6B73A6A97 for <lisp@core3.amsl.com>; Fri, 20 Mar 2009 07:41:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 2mjfnYvPNaOL for <lisp@core3.amsl.com>; Fri, 20 Mar 2009 07:41:00 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id EA15E3A6A1F for <lisp@ietf.org>; Fri, 20 Mar 2009 07:40:59 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CADA54144; Fri, 20 Mar 2009 10:41:37 -0400 (EDT)
To: Robin Whittle <rw@firstpr.com.au>
References: <20090318024449.DD3CA6BE556@mercury.lcs.mit.edu> <49C194DE.6060502@firstpr.com.au> <7B0C1C66-3231-4C27-83C9-B06E851F3CBB@cisco.com> <49C19BD2.7090800@firstpr.com.au> <EEB6118D-ABFF-40C6-B8F5-3940B41085C7@cisco.com> <49C1B570.5030203@firstpr.com.au> <tsliqm5zmjo.fsf@mit.edu> <49C36337.6060606@firstpr.com.au>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Fri, 20 Mar 2009 10:41:37 -0400
In-Reply-To: <49C36337.6060606@firstpr.com.au> (Robin Whittle's message of "Fri\, 20 Mar 2009 20\:34\:47 +1100")
Message-ID: <tsl4oxop87y.fsf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: lisp@ietf.org, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: Re: [lisp] [ipdir] LISP WG: Loc/ID separation - not separate namespaces
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: Fri, 20 Mar 2009 14:41:00 -0000

Hi.
I'd like to focus discussion on the specific goals you propose for your charter changes.


>  A description of LISP as being part of the "core-edge separation"
>  class of scalable routing solutions, noting that "map-and-encap"
>  was a term used earlier on for this class.

So far, you are the only one who has advanced this particular
terminology distinction as important.  I'd appreciate hearing comments
from others.

>  An understanding that EID space is purely for end-user networks, to
>  provide multihoming etc. in a scalable fashion.

Your changes in this area may be part of addressing the concern that Margaret, Lixia, and I believe Bryan raised.
I think from your most recent messages you may share that concern.

>  An introduction to ITRs and ETRs and description of what they do.

Again, comments welcome from others.

>  A clearer understanding of Locator Identifier Separation in terms
>  of it:

>     Not involving separate namespaces - contrary to incorrect
>     statements about LISP in an IETF Journal article etc. and
>     in contrast to the HIP approach to Locator Identifier Separation
>     which does involve separate namespaces.

You've presented one definition of namespace.  I strongly suspect that
there are a lot of other definitions floating around and that the term
was being used loosely.  I have not seen a lot of support for your
strict definition of namespaces.  However, I think that addressing
Bryan, Lixia and Margaret's concern needs to be addressed by making
this distinction clear.  I think that avoiding the term namespace or
defining what we mean by namespace will be more productive than an
argument over its definition and whether we have found the clearly
correct definition for our field.  At least as I understand it, your
proposed charter text change in this area seems to do this.

>     Being an operational distinction in how addresses in different
>     sub-sections of the address range (perhaps we should mention
>     global unicast address range).

I think something along these lines is starting to sound like it is needed.

>>     This distinction only being applicable to ITRs and ETRs - not to
>     hosts or ordinary routers.


As I understand it, the only XTRs need to care about EID vs RLOC
distinctions is one of the core design goals of LISP.  It seems like
including it in the charter may add clarity and constrain our work.

v2.23.0 | Report a Bug | By Email