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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 19 March 2009 13:09 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 D88F928C269 for <lisp@core3.amsl.com>; Thu, 19 Mar 2009 06:09:10 -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 zPBu4owGud0h for <lisp@core3.amsl.com>; Thu, 19 Mar 2009 06:09:10 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id C170828C14B for <lisp@ietf.org>; Thu, 19 Mar 2009 06:09:09 -0700 (PDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BF9DE4249; Thu, 19 Mar 2009 09:09:47 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
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>
Date: Thu, 19 Mar 2009 09:09:47 -0400
In-Reply-To: <49C1B570.5030203@firstpr.com.au> (Robin Whittle's message of "Thu, 19 Mar 2009 14:01:04 +1100")
Message-ID: <tsliqm5zmjo.fsf@mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (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: Thu, 19 Mar 2009 13:09:10 -0000

>>>>> "Robin" == Robin Whittle <rw@firstpr.com.au> writes:

    Robin> Short version: I think these I-Ds contain incorrect usage
    Robin> of the term "namespace":

At least to the extent that you copy the lisp@ietf.org list can you
please state your concern about the use of terminology in terms of the
affect of that concern?

After multiple readings of your message, I'm still somewhat confused
about your point.  You seem to be saying that the Namespace is a
really generic term that can mean a lot of different things.  You seem
to be concerned about some lack of clarity in the drafts.  I think
your main point is that you do not believe that a single IP address
can stand as both an RLOC and an EID.  I agree there are definitions
of namespace where saying that EIDs and RLOCs are in the same
namespace means this and no more.  There are other reasonable
definitions of namespace, for example definitions under which ULAs and
PA IPV6 addresses are in different namespaces, for which saying that
EIDs and RLOCs are in the same namespace says far more than you need to if I've captured your point above.

So, let's step past the terminology argument and examine your point.
First, have I got your point right?  Am I missing part of it?

It does not seem absolutely true that  the same bit pattern cannot be an EID and an RLOC.
Here are ways in which this may be false:

1) As discussed in section 4 of the interworking draft, you can
   announce an EID as an RLOC.  This is meaningful if the address
   would reach the same entity regardless of whether you treat it as
   an EID or RLOC.  That section discusses disadvantages of doing so,
   but does not forbid the practice.  (Clearly, if new EIDs are
   announced as RLOCs, we are making the routing problem worse.  It's
   not clear to me that using something as both an EID and RLOC that
   is already announced in the DFZ actually makes things significantly
   worse.)


2)  The RFC 2547 VPN case is actually important.  You discuss some of the conditions that would be necessary for this to be done within an ISP as an argument that it couldn't work.  For example, routers would need to keep track of which 10.1.0.1 they were dealing with.  You propose that a bit would be needed in the IPV4 header.

It turns out that this practice is quite common today.  Typically MPLS
labels are used to distinguish what addressing plan an address is
drawn from in cases where there are multiple valid addressing plans
for an interface.  (It's a bit more complicated than this in
actuality).  However in a number of cases (particularly the CE
interfaces), only one addressing plan is valid.  The routers
definitely do support maintaining separate routing tables and keeping the routing separate.

If you had a mapping function local to an ISP, you absolutely could
return EID->RLOC mappings local to the addressing plan of that ISP.
If the EIDs are not globally unique, then you'll only be able to reach
that EID from within the scope where it is unique.  However non-unique
RLOCs don't seem like they would cause any significant problem.  If
the EID was outside the ISP, then the mapping service could give you
the RLOC of a router that would decapsulate-and-reencapsulate your
packet with a new RLOC.

Is this useful?  I don't know.  Will it be permitted by our eventual
specs?  Who knows.  Will it be technically possibly regardless of
anything we do?  Almost certainly yes.

However, I think there is a core of your concern that is an important
clarification to the drafts.  In many cases, you cannot use the same
number as an EID and an RLOC.

I'd ask us all to focus on figuring out how to explain that, rather
than telling people that they have incorrectly used the term
namespace, or their identifiers are not "true identifiers" (whatever
truth is),or complaining that we cannot go back and change mailing
list messages.