Re: [lisp] LISP EID Block Size

Dino Farinacci <farinacci@gmail.com> Thu, 31 October 2013 12:57 UTC

Return-Path: <farinacci@gmail.com>
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 2230021E80ED for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 05:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 voeVHeLdXtzi for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 05:57:53 -0700 (PDT)
Received: from mail-qe0-x232.google.com (mail-qe0-x232.google.com [IPv6:2607:f8b0:400d:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8182421E8064 for <lisp@ietf.org>; Thu, 31 Oct 2013 05:57:48 -0700 (PDT)
Received: by mail-qe0-f50.google.com with SMTP id 1so1694944qee.9 for <lisp@ietf.org>; Thu, 31 Oct 2013 05:57:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=i83QYZxuji97a8ZBKhTcd1n2eLfTWVB46kPwIPvkMLE=; b=IAchyP/Y+k5fi83u13IxCFGQTox3VqudrVYKOTh/THdgiC0955RQ7BDGIB4ztjZDC/ 36FQKabPYfaIlTDkwG7zUOLlBJ+XKeMI4j5jvTfwtbgLt47gFtjxBkjpOw3DZzTzbRm2 q8ZBMXKjPVlg9yEHeDAYxxHMF5qcB79Bc1n2zOQMulmO+xRYZtBPGuIRRMnTG6sL9m/r 1RDtTaAg9ZMKsL0aG5l7w1wSr2C3ntpslLtWM2ICozakPTNEq9+monqMkPLss5arvbxB FiGPSIZImlDhKtt10rixNopNpNFjCyJF7PlgqYo/DdnhyfTSoSlNQhXIY+/QPNluYlFi AiyQ==
X-Received: by 10.49.72.164 with SMTP id e4mr3923380qev.36.1383224257924; Thu, 31 Oct 2013 05:57:37 -0700 (PDT)
Received: from [10.5.70.49] (pool-96-224-3-231.nycmny.east.verizon.net. [96.224.3.231]) by mx.google.com with ESMTPSA id ge5sm6671638qeb.5.2013.10.31.05.57.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 05:57:37 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net>
Date: Thu, 31 Oct 2013 05:57:37 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E6AD700C-DC48-48DB-9FF5-A24C6121834C@gmail.com>
References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.1816)
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, 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 12:57:57 -0000

Geoff, LISP can route the entire allocated address space (but just not requires it to be everywhere). So arguably, LISP can do this at much cheaper cost and complexity.

The reason for a dedicated block is similar to why we have an address block for IPv4 and IPv6 multicast. To experiment to see if a hard-coded block can provide any interesting ideas. That part is the experiment, not whole of LISP proper.

Dino

On Oct 30, 2013, at 10:02 PM, Geoff Huston <gih@apnic.net> wrote:

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