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.
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… HeinerHummel
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Noel Chiappa
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Dino Farinacci
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Robin Whittle
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Dino Farinacci
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Robin Whittle
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Dino Farinacci
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Robin Whittle
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… John Zwiebel
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Sam Hartman
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Robin Whittle
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Sam Hartman
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Scott Brim
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Sam Hartman
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Noel Chiappa
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Robin Whittle
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Sam Hartman
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Noel Chiappa
- Re: [lisp] [ipdir] LISP WG: Loc/ID separation - n… Sam Hartman