Re: [lisp] [Ila] LISP for ILA

Tom Herbert <> Fri, 16 March 2018 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64D30129515 for <>; Fri, 16 Mar 2018 12:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pEQUHJA4E1pQ for <>; Fri, 16 Mar 2018 12:33:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB1D71252BA for <>; Fri, 16 Mar 2018 12:33:37 -0700 (PDT)
Received: by with SMTP id h76so5100933wme.4 for <>; Fri, 16 Mar 2018 12:33:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YLV+X2fVJCz6midAT8PeEPJvWYoFH+jI/JW7A5YUPq8=; b=O1L5wfZf8E8eY/FVcUsKNZ8UxwcrBDadyFQSB2DozXmDiH8IbBRM7GzJpl0qplHuLD sMDue6NlLlsuleg5ZWF//O655O+dHscjldqiLy6S9uANvsWsvVQObe7Aw7dRC/y1HmNy LKpG84qyIaHYxN3A1ozi7dB0xmZmKhFxS1hTYCFlXiOPC4lrEb+GZU0zPhLuBkFHUfjj gi96wNjAepz9/azko/gD1ZQtWUIgKnBZFYnO8n42kGFBm1aK9Q1zAGbk8zVcgIbftLro /Bu/X7pi3KX7fngu8Mv4/Zl0qv+rJDb+/jLrLgitOWNGlsp1D5f19hai88CYQrVSXhqs 9rZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YLV+X2fVJCz6midAT8PeEPJvWYoFH+jI/JW7A5YUPq8=; b=ejGEXLXfTXq55K0VnCntD7JwaZ0qGZqcGeKqYXr1Er1q88/VROXyFKzOg7g0mAHfR0 Xwzg7a7J5FHpo38iA4gehn3vWtK1yi5LEuvqdVVZik7tUDII5WsoitgYNP8zkC8EqX9O 3MO/R6uo3JNc7Dk+1DZ0pozvL4OiyNHg2zi3IOr892/RQi7LUNmq/ClBqZ1cCOOkINHm eJMm5vPDsk95sxsazSgLsWjBlvBSQHzafYFVsmkEBVe4miCxZ8MEoKMnJ8GkQDQnS7sF 5/3W/cTwjhh2BXntlgCQFqO11Y0Smpv6ybQ7iiOa7xGMWFCzbATk4h2aFdnQxSvE6tZq pAog==
X-Gm-Message-State: AElRT7GXfkUGAT/j1KpVY15rGB8tdSAT6BN3RyVeWLSf5/KBg4Y1uZ3m LMI3Is5ZfjK0ZpUdwoEMN716hp/ggj4pvrBVbjGUdA==
X-Google-Smtp-Source: AG47ELug7nvRDvUN+oqxOw8sHNydqOtyUD+LafsUjWoCItfZYsRAchUlA302QwLtaEGC2x5KLynuk5qHIuDTvVeai7Q=
X-Received: by with SMTP id l202mr2494521wmb.32.1521228816192; Fri, 16 Mar 2018 12:33:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 16 Mar 2018 12:33:35 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 16 Mar 2018 12:33:35 -0700
Message-ID: <>
To: Dino Farinacci <>
Cc: Florin Coras <>, "Alberto Rodriguez Natal (natal)" <>, "" <>, "" <>, David Meyer <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [lisp] [Ila] LISP for ILA
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: Fri, 16 Mar 2018 19:33:40 -0000

On Fri, Mar 16, 2018 at 12:17 PM, Dino Farinacci <> wrote:
>> Such complexity is why I am still keen on the redirect model for a
> I hear you loud and clear. But we do the redirect model in LISP in many forms as well.
>> mapping system. An ILA cache is an optional element and the control
>> plane is never inline with packet forwarding and packets are not
>> dropped on a cache miss. Neither does the generate request packets for
> We did that in the ITR as well. A cache missed meant to send a Map-Request and to encapsulate the packet to a PETR (proxy decapsulator) where the PETR usually had a full cache (how it got populated could be with pull or push mechanisms).
> But this results in duplicate packets going to the destination as well as out of order packets.
>> bogus addresses that can't resolved. These properties bound the worse
>> case DOS attack to be that legitimate traffic takes an unoptimized
>> route but is not blocked nor dropped. Conservatively, this does
> 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.


>> require provisioning ILA-Rs to handle the full load if necessary to be
>> robust.
> Yes indeed.
> Dino