Re: [lisp] LISP EID Block Size (Noel Chiappa) Thu, 31 October 2013 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 467BF11E8160 for <>; Thu, 31 Oct 2013 12:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.525
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ksqjsGVRwA0g for <>; Thu, 31 Oct 2013 12:54:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ABC5121F9CAC for <>; Thu, 31 Oct 2013 12:54:54 -0700 (PDT)
Received: by (Postfix, from userid 11178) id EAA1318C17C; Thu, 31 Oct 2013 15:54:53 -0400 (EDT)
Message-Id: <>
Date: Thu, 31 Oct 2013 15:54:53 -0400 (EDT)
From: (Noel Chiappa)
Subject: Re: [lisp] LISP EID Block Size
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 19:55:12 -0000

    > From: Roger Jorgensen <>

    > 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

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".