IETF Logo Mail Archive

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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Wed, 18 March 2009 19:51 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 936EA28C0CE for <lisp@core3.amsl.com>; Wed, 18 Mar 2009 12:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.13
X-Spam-Level:
X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, 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 e0eO7k+53gGq for <lisp@core3.amsl.com>; Wed, 18 Mar 2009 12:51:52 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id BF8613A6960 for <lisp@ietf.org>; Wed, 18 Mar 2009 12:51:52 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 419226BE574; Wed, 18 Mar 2009 15:52:36 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20090318195236.419226BE574@mercury.lcs.mit.edu>
Date: Wed, 18 Mar 2009 15:52:36 -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 19:51:53 -0000

    > From: "Templin, Fred L" <Fred.L.Templin@boeing.com>

    > I'm not sure about the analogy. If I assign the same interface ID on
    > multiple interfaces of the same node, it works fine ... But, if I
    > assign the same IP address on multiple interfaces of the same node 

Which is part of why I said "the properties of the LISP EID are extremely
similar to an IEEE Interface ID" - not 'identical to'! The problem you point
out was one of the differences I identified, in thinking about it.


To be exact, even if mapping-encapsulation functionality is in first-hop
routers at a site, if an ETR is connected to multiple physical networks at
such a site, then when a packet arrives either:

- i) the ETR has to have a table, identifying which physical network each
  LISP EID is on; or
- ii) something in the LISP EID must identify which physical network the
  host the packet is for is attached to; or
- iii) something in the RLOC must identify said network.

i) isn't exactly infeasible - that's basically what bridges do already. ii)
is what the current scheme is - and it means that LISP EIDs have to retain
some location semantics. iii) would need some support, probably through
assignment of a new RLOC AFI to carry a tuple (the ETR's locator, plus a
destination physical network selector), plus some information in the
encapsulation header(to carry the destination physical network selector). Not
sure which is best - or perhaps all might be used, in different situations.


    > I am still offering Endpoint Interface iDentifeir (EID)

I like it, but... if LISP evolves to the point where LISP EIDs become purely
stack identifiers (which is what I would like to see, long-term), and
interfaces are named from a new locator namespace (yes, I know this requires
host changes), then LISP EIDs would not in fact name interfaces any more.

The only piece of functionality that _cannot_ be leached out of an IPvN
address, _if interoperability with unmodified hosts is to be maintained_, is
their identification of stacks. (Note that having interfaces named from a new
locator namespace is perfectly feasible, because that would only be visible
_locally_ - the host on the far end of e.g. a TCP connection would not
necessarily be aware that that was happening on the other end.)

	Noel

v2.23.0 | Report a Bug | By Email