Re: [lisp] [Ila] LISP for ILA

Dino Farinacci <> Fri, 16 March 2018 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6133129515; Fri, 16 Mar 2018 12:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 J6cJaWpHZ6eW; Fri, 16 Mar 2018 12:17:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6744E1252BA; Fri, 16 Mar 2018 12:17:48 -0700 (PDT)
Received: by with SMTP id v9-v6so6466689plp.12; Fri, 16 Mar 2018 12:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HR7SvmPouysQLrrp9B9eaBSeJvTk/VK3iUis93FwTng=; b=UcshQYM0axVb/yrsm56neidQsXzcv3tDlddgephUAbQ9RzdE9FnqfaEIPdtDiPSW6w qd//bpx/85AHFKlUAnCjRuVGco9yRhihKnytvSp+R1MROqEbnNsHw3edSu6YzBo7ikLv RRCzX+d7TQ7T0VfyJ4t7qC4ZHyVrVYq51f9xOGCA8EEuh+w9uiu36yc3Ur8yf+Vp3yCh s2ufEQ1/rdF0CygAH3nCEedXtta+wjW6v8twtCsumfHXWEjeKTFnYbIqSte8HSjSrwJl 41o8Imr3rLzkYaWWdSiy1XDIJ7MoyG3qk9ShCyIyHDrhSZD5ay4Kucr20raLe+ng3C+7 e4zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HR7SvmPouysQLrrp9B9eaBSeJvTk/VK3iUis93FwTng=; b=Z8lavDMGBiH4XLffXsbz0w433horGYbaDjg8+3BlrRI79ih5eo3wOaEYFDoTikqcQG Bb2lch0joJ5UyCnrAmf8S+HPYz+a5U/E90Of99I4rDhrL40RhQUqNTR0IeNU7uDZfO+z mrKV5ZMM+mG9VWYM7pIPmKgfTYFhVOJ15BldR4LmFH9LulTRtpP/P9y7wUUfKA9uJ9RM YGgxS40uh7KeB5jgef6sQ8lVRJRtGcBy8Jd3fimBhAjTehTX4FlnfJIpvxOnRn0dL77U qm9SEYNj1FgvBTNsydevA/4i0+OHtnKueGD57eBJoxfcIJneDejyzuciO72e3xt0cPj7 aNtQ==
X-Gm-Message-State: AElRT7G2usal4mNVMO0H//saobfJk4QEPDdK/tejTnzjCvLdoWvYqdET 6GpOjsqk1whZQw+MbehrTJg=
X-Google-Smtp-Source: AG47ELvou7m7iRmlwjPOXYhV0rC/SiwjN4sUBoDEUkaUgm/iHWrHEwMBLgFAFOzHbqox98m/mVTaww==
X-Received: by 2002:a17:902:8684:: with SMTP id g4-v6mr407188plo.117.1521227868083; Fri, 16 Mar 2018 12:17:48 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id 2sm18051748pfo.70.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Mar 2018 12:17:47 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 16 Mar 2018 12:17:46 -0700
Cc: Florin Coras <>, "Alberto Rodriguez Natal (natal)" <>, "" <>, "" <>, David Meyer <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3445.5.20)
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:17:49 -0000

> 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.

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

Yes indeed.