Re: [lisp] LISP EID Block Size

George Michaelson <ggm@algebras.org> Thu, 31 October 2013 20:41 UTC

Return-Path: <ggm@algebras.org>
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 0C93211E823F for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 13:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 U0YxDrWdwYb4 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 13:41:39 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBC11E81A9 for <lisp@ietf.org>; Thu, 31 Oct 2013 13:41:29 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id g10so2893193pdj.21 for <lisp@ietf.org>; Thu, 31 Oct 2013 13:41:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PpKPr4lWy6hyvpM+q9SHRYumHG7jMMwrYkDRmzTyksY=; b=TaWslQssDWn50oVgc3KItivb66devQPo1rUay2WZd0VOt0iWD4+WJzpvxEbSiC+AnS O/luLHE7TP1P8qoFMkr0ofZXtafX1ucwH0/MIOCEVQP2+BzUltiYXQexaVbk/Mwww33l F8L+WLS+bqJpvkVZ3C/oR3/DwkhtvtdPdEkUpfzasOkHCSXqpNUJemygCh7qmkoXkyka qLYRC8UKa+HIsDx9HXd2gsV/J2sVq8iNeRc/BiQDdVNdNmjJiJkX3mu/cGudqqPCoDqM gR56T7fZpSPuOTn9alFQvs8RZox1PPSzAUkw6uyPWERTToIw3IQh15Jh7yvrMRX+OsFx heWQ==
X-Gm-Message-State: ALoCoQmYO9lwdY7fcE6WtF/OaCBVx9TlCEJNCB2i1Tr9EYk/IfIE5CouXXcZFeWLSKNShMac8Z7z
MIME-Version: 1.0
X-Received: by 10.66.155.36 with SMTP id vt4mr3867140pab.93.1383252085780; Thu, 31 Oct 2013 13:41:25 -0700 (PDT)
Received: by 10.70.19.98 with HTTP; Thu, 31 Oct 2013 13:41:25 -0700 (PDT)
X-Originating-IP: [198.233.81.21]
In-Reply-To: <20131031195453.EAA1318C17C@mercury.lcs.mit.edu>
References: <20131031195453.EAA1318C17C@mercury.lcs.mit.edu>
Date: Thu, 31 Oct 2013 20:41:25 +0000
Message-ID: <CAKr6gn0C9Uj7LPWE_a=awr7C5T_uGmbdYxKPzc-HE+CZZpDPeg@mail.gmail.com>
From: George Michaelson <ggm@algebras.org>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Content-Type: multipart/alternative; boundary="047d7bacc01a3550a604ea0f797c"
Cc: lisp@ietf.org
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 20:41:44 -0000

you can achieve this goal from a /32. what you're seeking to avoid is
having to re-map the magic prefix if the experiment is a success: this I
understand. But the cost of wiring a prefix is a very high cost: code
should be written to be agile and be able to be TOLD what prefix is the
magic prefix. Nobody should be reifying prefixes into anything, experiment
or otherwise.

Make it a parameter of prefix/len.

And work the experiment in a /32


On Thu, Oct 31, 2013 at 7:54 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu>wrote:

>     > 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
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>