Re: [lisp] LISP EID Block Size

Rene Bartsch <ietf@bartschnet.de> Fri, 01 November 2013 10:51 UTC

Return-Path: <ietf@bartschnet.de>
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 BE19621E80B8 for <lisp@ietfa.amsl.com>; Fri, 1 Nov 2013 03:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.859
X-Spam-Level:
X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_MILLIONSOF=0.315]
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 U6IofprXYpbn for <lisp@ietfa.amsl.com>; Fri, 1 Nov 2013 03:51:15 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABDE21F9F96 for <lisp@ietf.org>; Fri, 1 Nov 2013 03:51:13 -0700 (PDT)
Received: from [80.67.16.118] (helo=www.premium-webmail.de) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from <ietf@bartschnet.de>) id 1VcCJr-0002gQ-Vx for lisp@ietf.org; Fri, 01 Nov 2013 11:51:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 01 Nov 2013 11:51:11 +0100
From: Rene Bartsch <ietf@bartschnet.de>
To: lisp@ietf.org
In-Reply-To: <D68CD130-50BC-42AE-95E5-A4EBEEB20808@apnic.net>
References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <E6AD700C-DC48-48DB-9FF5-A24C6121834C@gmail.com> <D68CD130-50BC-42AE-95E5-A4EBEEB20808@apnic.net>
Message-ID: <8119249a5b4cb0604726fa7560538cf3@bartschnet.de>
X-Sender: ietf@bartschnet.de
User-Agent: Roundcube Webmail
X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl
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: Fri, 01 Nov 2013 10:51:20 -0000

Am 2013-10-31 22:36, schrieb Geoff Huston:
> On 31 Oct 2013, at 11:57 pm, Dino Farinacci <farinacci@gmail.com> 
> wrote:
> 
>> 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.
> 
> 
> On the LISP page I already see LISP using IPv4 and IPv6 blocks for
> this experiment. So what have you found out already in terms of
> "interesting ideas"? What do you think that a larger block would
> inform you that is not possible with the existing block?
> 
> (using /56 end site prefixes a /32 can accommodate 16,777,216 end
> sites of course, and even at a 10% utilisation level thats 1.7 million
> end sites. So I;'m kinds mystified why a .32 can't tell you about
> scaling given that we are talking of the order of 10**6 end sites
> within such a block.)

The success of the internet is based on experiments which directly 
scaled into production (like the IP protocol by Cerf and Kahn). Remind 
the pain we have with the IPv4->IPv6-transition because there are not 
enough IPv4-addresses for the whole internet-community. If you just go 
for tiny experiments - like the last 6 years - LISP will never go on air 
for the internet-community. Currently AVM provides a great chance to go 
an air by integrating LISP into millions of consumer-routers 'til end of 
the year and we shouldn't scare them away by a never-ending experiment.

If consumers adopt LISP, we'll need 10,000,000,000 prefixes within the 
next ten years. That means each public PITR will have to announce 
10,000,000,000 BGP-routes to itself if consumers use random PI-prefixes 
from the global unicast space. Multiply the number of public PITRs 
necessary for such a deployment with 10,000,000,000 BGP-routes each and 
you'll realize LISP will either break the internet and go into decline 
or just be a limited luxury for big companies. Using a dedicated 
PI-prefix which can handle 10,000,000,000 subnets will reduce the 
BGP-routes a public PITR has to announce to ONE. So using 24 or 32 bits 
is way to less for the expected growth.

I want to ask everyone on the list: Which facts prevent a scaling 
experiment with the aim of global production state? In my opinion a 
/16-EID-prefix is perfect for that goal.

Best regards,

Renne