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
- [lisp] Fwd: Comments about draft-cheng-lisp-shdht… cheng.li2
- Re: [lisp] Fwd: Comments about draft-cheng-lisp-s… Noel Chiappa
- Re: [lisp] Fwd: Comments about draft-cheng-lisp-s… Michael Hoefling
- Re: [lisp] Fwd: Comments about draft-cheng-lisp-s… Michael Hoefling
- Re: [lisp] Fwd: Comments about draft-cheng-lisp-s… Noel Chiappa
- [lisp] 答复: Re: Fwd: Comments about draft-cheng-li… cheng.li2