Re: [lisp] Fwd: Comments about draft-cheng-lisp-shdht-01

jnc@mercury.lcs.mit.edu (Noel Chiappa) Fri, 27 July 2012 13:23 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F4821F8691 for <lisp@ietfa.amsl.com>; Fri, 27 Jul 2012 06:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.253
X-Spam-Level:
X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA-sRY01a0qo for <lisp@ietfa.amsl.com>; Fri, 27 Jul 2012 06:23:55 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDFB21F8688 for <lisp@ietf.org>; Fri, 27 Jul 2012 06:23:55 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 8689C18C0DB; Fri, 27 Jul 2012 09:23:54 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20120727132354.8689C18C0DB@mercury.lcs.mit.edu>
Date: Fri, 27 Jul 2012 09:23:54 -0400
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] Fwd: Comments about draft-cheng-lisp-shdht-01
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 27 Jul 2012 13:23:56 -0000

    > From: Michael Hoefling <hoefling@informatik.uni-tuebingen.de>

    > I assume that the proxy reply mode should not be the default operation
    > mode.
    > ... no P-bit not proxy.

That's my understanding - but sometimes I get a little confused on these fine
details! So if I have made a mistake, I trust someone will let us know! :-)

The whole question of having to get the mappings from the ETRs is one I have
thought about a fair amount, because it (currently) makes it impossible to
cache mappings in, e.g., the MR.

(Let me quickly clarify that "currently" - although I have thought about how
to cache mappings, I don't believe there are any plans to do so at the moment
- at least, not that I am aware of. It would require changing the Map-Reply
format, to indicate which ranges of 'source' EIDs a particular mapping is
valid for. So unless we have to change the Map-Reply format for some other
reason - e.g. to include signatures on mappings - my guess is that this is
unlikely to happen. And it's not clear if we need to cache mappings at
intermediate points between the authoritative source [the ETR] and the user
[the ITR] - although the DNS does have this capability, IIRC. Well, that's
the kind of thing we will discover through trying it...)

It is a slightly odd design choice in a way - it's a bit of an odd form for
the subsystem boundary (compared to other systems which provide mappings). It
wasn't until I started thinking of the ALT/etc as 'indexing systems' (which
is not how they were orginally described, I think) that it started to be
easier for me to think about. 


    >> This is necessary for things like 'source-specific mappings' (where an
    >> ETR returns different mappings to different ITRs).

    > Isn't this possible in proxy mode as well or is the selection logic
    > specific for ETRs?

Well, there is no way in the ETR/MS interface to specify that there are
multiple mappings, and which mappings should be given to which sources. So,
it is necessarily onl the ETRs which can provide source-specific mappings.

    > How is this currently achieved in DNS?

Do you mean 'how does DNS return different mappings to differerent lookup
requests' (as I gather a few people do, for load-balancing reasons, etc etc).
I don't know the details - I assume it's implementation-specific.

	Noel