Re: [lisp] LISP EID Block Size

jnc@mercury.lcs.mit.edu (Noel Chiappa) Thu, 31 October 2013 19:55 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 467BF11E8160 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 12:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.525
X-Spam-Level:
X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, 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 ksqjsGVRwA0g for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 12:54:56 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id ABC5121F9CAC for <lisp@ietf.org>; Thu, 31 Oct 2013 12:54:54 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EAA1318C17C; Thu, 31 Oct 2013 15:54:53 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20131031195453.EAA1318C17C@mercury.lcs.mit.edu>
Date: Thu, 31 Oct 2013 15:54:53 -0400
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] LISP EID Block Size
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: Thu, 31 Oct 2013 19:55:12 -0000

    > From: Roger Jorgensen <rogerj@gmail.com>

    > The _big_ difference between EID's out there today, and the one from
    > this new netblock are that any system should _know_ by matching the IP
    > that this is EID space, and by that know how to handle it.
    > If traffic grow as everyone predict, and continue todo so, optimizing
    > the handling of LISP EID's is probably a very good idea.

Sure, but realize that there are limits on the improvement of basic LISP
handling.

E.g. if we allocate a large number of PI blocks from a large EID block, an
ITR will likely _still_ have to do a mapping lookup cycle in order to be able
to forward traffic to an PI EID block's ETR. (Since there would be many
different PI blocks allocated from that large PI block, scattered all over
the Internet.)

Yes, the 'interoperation with legacy hosts' part would be better, since there
would only need to be a single large advertisement into the legacy DFZ (as
someone else pointed out).

And who knows, maybe someone will develop a use-case in which 'facial' EIDs
bring more significant benefits. But I think Darrel's point is very accurate:
"we should keep our expectations for the benefits of this block modest".

	Noel