IETF Logo Mail Archive

Re: [lisp] Capabilities Type LCAF - a proposal

jnc@mercury.lcs.mit.edu (Noel Chiappa) Wed, 20 November 2013 12:41 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333941ADF69 for <lisp@ietfa.amsl.com>; Wed, 20 Nov 2013 04:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level:
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FrXZqLwjTZP for <lisp@ietfa.amsl.com>; Wed, 20 Nov 2013 04:41:50 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFFE1ADF5D for <lisp@ietf.org>; Wed, 20 Nov 2013 04:41:50 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id CD2B618C147; Wed, 20 Nov 2013 07:41:43 -0500 (EST)
To: lisp@ietf.org
Message-Id: <20131120124143.CD2B618C147@mercury.lcs.mit.edu>
Date: Wed, 20 Nov 2013 07:41:43 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] Capabilities Type LCAF - a proposal
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 20 Nov 2013 12:41:51 -0000

    > From: Damien Saucez <damien.saucez@gmail.com>

    > I would have a question, if there is capability, it means that there is
    > a possibility to meet no capability so in this case what is replied?
    > ...
    > If 0 locators then it is a negative reply but conceptually this is not
    > a negative reply. If no answer, then the requester will keep continuing
    > sending requests.

Good points.

In general, I don't think we should keep tweaking Map-Request and Map-Reply
messages 'because they are there'. If we need to extend semantics, let's do
it right.

    > If a new message, what kind of message?

The has been some discussion about adding a new message-type to fill a
variety of roles which involve transferring information around (e.g.
dynamically loading configuration information such as default PxTRs into
small xTRs, a la DHCP, instead of having to manuall configure them).

This would seem to naturally fall into that general classification?

	Noel

v2.23.0 | Report a Bug | By Email