Re: [lisp] [Ila] LISP for ILA - scaling

"" <> Sat, 17 March 2018 01:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 563D9126C19; Fri, 16 Mar 2018 18:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HehPvpXjUpws; Fri, 16 Mar 2018 18:41:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17C21126C3D; Fri, 16 Mar 2018 18:41:05 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E66591C01F9; Fri, 16 Mar 2018 18:41:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=2.tigertech; t=1521250864; bh=fwQ8uqVKhwax3oniKwA1E0RrFlI8F5NNRKfBBlxu8Ag=; h=Date:Subject:In-Reply-To:From:To:Cc:From; b=dIWT3tVkTFvQWt88zCklfDESBaK5mqbvd11FrBm22AnhHQgGgU0WlOhkiU1M0M5Fi OJgtN3ik1FqUoPo4M5s3xP7K9W3DMljFlQRrVH28sHthX5oSSI+/JOZP+tvbMLjDjm soIQJZyAcZSRCGF8zqUvaXL3Bjkrr6QPuEI59H7M=
X-Virus-Scanned: Debian amavisd-new at
Received: from [IPv6:2600:380:1975:73c3:a0ed:3c16:f445:1888] (unknown [IPv6:2600:380:1975:73c3:a0ed:3c16:f445:1888]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id D058B1C0107; Fri, 16 Mar 2018 18:41:03 -0700 (PDT)
Date: Fri, 16 Mar 2018 21:41:01 -0400
In-Reply-To: <>
Importance: normal
From: "" <>
To: Dino Farinacci <>, "Joel M. Halpern" <>
Cc: Tom Herbert <>, David Meyer <>, "Alberto Rodriguez Natal (natal)" <>, Florin Coras <>, "" <>, "" <>, Eliot Lear <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
Message-Id: <>
Archived-At: <>
Subject: Re: [lisp] [Ila] LISP for ILA - scaling
X-Mailman-Version: 2.1.22
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: Sat, 17 Mar 2018 01:41:07 -0000

His analysis of the control push size did not go to 1 billion.  That is why I stated that for any constrained environment push would work.  I do not know of a use case for 1 billion entities in those constraints.Internet-scale is a different problem.

Sent via the Samsung Galaxy S® 6, an AT&T 4G LTE smartphone
-------- Original message --------From: Dino Farinacci <> Date: 3/16/18  20:44  (GMT-05:00) To: "Joel M. Halpern" <> Cc: Tom Herbert <>, David Meyer <>, "Alberto Rodriguez Natal (natal)" <>, Florin Coras <>,,, Eliot Lear <> Subject: Re: [Ila] [lisp] LISP for ILA - scaling 
Copying Eliot.

I don’t remember Eliot analyzing the data-plane. But he did see how far the mapping database could scale with push and don’t recall he saying 1 billion would be achievable either.


> On Mar 16, 2018, at 2:53 PM, Joel M. Halpern <> wrote:
> From the analysis Eliot did many years ago for a LISP push solution, for any constrained solution (a data center, a mobile operator, a fixed service operator) the number of entries is probably not a problem.  Even for a conventional router.  Churn rate, in its various manifestations, could well be an issue.
> Sharding is but one of several ways to divide and conquer to avoid those issues.  Separating control load from data plane load is also a useful way to help keep things manageable.
> Yours,
> Joel
> On 3/16/18 3:33 PM, Tom Herbert wrote:
>> On Fri, Mar 16, 2018 at 12:17 PM, Dino Farinacci <> wrote:
>>> Yes, understand. But even in your constrained “domain”, there may be just too much state to push to all nodes. Especially in the 5G use-case. It wasn’t a problem in the LISP beta network because the proxy xTRs had relatively coarse prefixes that reached lots of EIDs.
>> The state would need to be sharded. You'd probably need to do this
>> anyway for mapping-servers or high thoughput Internet facing routers
>> for which using a cache would be challenging.
>> Tom
>>>> require provisioning ILA-Rs to handle the full load if necessary to be
>>>> robust.
>>> Yes indeed.
>>> Dino
>> _______________________________________________
>> ila mailing list