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

jnc@mercury.lcs.mit.edu (Noel Chiappa) Fri, 27 July 2012 03:59 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 89EB921F85AC for <lisp@ietfa.amsl.com>; Thu, 26 Jul 2012 20:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.233
X-Spam-Level:
X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.366, 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 QC+GBrSu2GDH for <lisp@ietfa.amsl.com>; Thu, 26 Jul 2012 20:59:28 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 02B1821F85A8 for <lisp@ietf.org>; Thu, 26 Jul 2012 20:59:27 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0A19218C104; Thu, 26 Jul 2012 23:59:27 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20120727035927.0A19218C104@mercury.lcs.mit.edu>
Date: Thu, 26 Jul 2012 23:59:27 -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 03:59:28 -0000

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

    >> Noel Chiappa write two drafts about the overall LISP architecture:
    >>
    >> There, it is stated that - in accordance to the standard documents -
    >> ETRs are the only authoritative source for mapping information.

Well, they are introductions, not protocol specifications, so do not expect to
see every last detail in them. And they are also initial drafts, so there
might be minor errors in them. So you should be wary of citing them as
authorities on anything! :-)

Also, in the introduction document I do in fact note there that there are
_some_ circumstances in which the MS replies on behalf of the ETR: "in some
circumstances it is advantageous to allow the MS to proxy reply on the ETR's
behalf to Map-Request messages".


    > From: cheng.li2@zte.com.cn

    > In our drat, ETRs are still the authoritative source for mapping
    > information.
    >  ...
    >  When an ETR sends a Map-Register Message requesting for the Map-Server
    >  to proxy Map-Reply, it will set the p bit to 1.
    > In our draft, SHDHT Nodes could be considered as Map-Servers which
    > implement the "Proxy Map Reply" mode.

I am not sure I understand what you mean here. Does the SHDHT node _always_
reply to the ITR on behalf of the ETR? That is what I understand from reading
the -00 version of the I-D, and you seem to confirm that above.

However, the 'proxy reply' mode is only done when the _ETR asks_ for the MS
to do it; the MS does not get to do it whenever it wants. If the ETR does not
set the 'P' bit, the MS _cannot_ proxy reply on behalf of the ETR.

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

        Noel