Re: [lisp] LISP EID Block Size

Rene Bartsch <> Fri, 01 November 2013 10:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE19621E80B8 for <>; Fri, 1 Nov 2013 03:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.859
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U6IofprXYpbn for <>; Fri, 1 Nov 2013 03:51:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9ABDE21F9F96 for <>; Fri, 1 Nov 2013 03:51:13 -0700 (PDT)
Received: from [] ( by with esmtpa (Exim 4.68) (envelope-from <>) id 1VcCJr-0002gQ-Vx for; 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 <>
In-Reply-To: <>
References: <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail
X-Df-Sender: cmVuZUBiYXJ0c2NobmV0LmRl
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: 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 <> 
> 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,