Re: [lisp] LISP EID Block Size

Geoff Huston <gih@apnic.net> Thu, 31 October 2013 05:02 UTC

Return-Path: <gih@apnic.net>
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 7DCE611E82B4 for <lisp@ietfa.amsl.com>; Wed, 30 Oct 2013 22:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.443
X-Spam-Level:
X-Spam-Status: No, score=-99.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
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 zU2jJ2U8zfI5 for <lisp@ietfa.amsl.com>; Wed, 30 Oct 2013 22:02:27 -0700 (PDT)
Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id DBC1911E819C for <lisp@ietf.org>; Wed, 30 Oct 2013 22:02:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=Fw2j0db1TtKLohbjMjq5uPz1e7JTPmRZu+bwk+zQdho=; b=WXfTNSj0RfpgeEHT3FGyeYsCiLeqRls0/Yrz59piVYxTtktQMugRitudQh/MBP58BKrryC/3+qAV6 wsBKnsLxqQGmPrU1Ps7F2QjUu9v5Ehrmac3hOml04MaCCqHyNuIqMYUQkWsZmBYUbVOit3B29C2TuD HMIKv0NcHkRWLUdo=
Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Thu, 31 Oct 2013 15:02:13 +1000 (EST)
Received: from dhcp150.potaroo.net (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 31 Oct 2013 15:02:13 +1000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <20131030154454.587D918C143@mercury.lcs.mit.edu>
Date: Thu, 31 Oct 2013 16:02:11 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net>
References: <20131030154454.587D918C143@mercury.lcs.mit.edu>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
X-Mailer: Apple Mail (2.1816)
Cc: LISP mailing list list <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 05:02:31 -0000

On 31 Oct 2013, at 2:44 am, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>> From: Luigi Iannone <ggx@gigix.net>
> 
>> Yet, one of the main critics during the review was about the size of
>> the block which seems too large.
> 
> System Architecture Rule #1:
> 
>  Any Fixed-Size Namespace Will Eventually Be Too Small
> 
> Given that a /12 represents .025% of the IPv6 namespace, _if_ LISP becomes a
> huge sucess, we're more likely to run into SAR #1; and if LISP does not
> become etc, are they really going to miss .025% of a namespace?
> 
>> Any thought about a change in the requested EID block size?
> 
> I think we got it right the first time.
> 

I don't understand this line of reasoning Noel. 

BGP is a huge success - it appears to route 100% of the address space. If LISP 
becomes a huge success then why wouldn't it route 100% of the address space, just
as BGP does today? And if it withers and dies then any dedicated address
allocation will be too much at that point in time. If this is all about an 
_experiment_ under some form of  experimental constraint then what are the
bounds of the experiment? What happens at the end of the experiment? Why would there 
be a continuing need to corral LISP into its own dedicated corner of the address
space? Is there something about scaling LISP to a full unicast routing scale that
simply does not work? Or is corralling of LISP into a dedicated block  of addresses
unnecessary? Why do I feel that this experiment has not been well thought through?
Or if it has, then it seems to me that the mapping of parameters of the proposed
experiment into the words in the two drafts relating to this proposed action
is still lacking.

regards,

    Geoff