Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]

Tom Herbert <> Tue, 01 May 2018 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1B9412E8D8 for <>; Tue, 1 May 2018 10:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 mPCsXYNkmQYW for <>; Tue, 1 May 2018 10:42:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC57312E8D3 for <>; Tue, 1 May 2018 10:42:08 -0700 (PDT)
Received: by with SMTP id a67so11156697wmf.3 for <>; Tue, 01 May 2018 10:42:08 -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=4LhqTyNArP25VUxVjib5mPxzI6yRiAR1RZWt9WIY7bI=; b=m9nI3mYN2jJxfdQbEM2S3uDYF2wPeHUtSmxgChh6j0mIkFS3N2UFphruWI1H5kmndy 8+4SRketXfq10FZm5aOH6fZ1M/30CLNnR4y5ebJMKL5h1mRNlgrnqUbwM/m4oQPpLdRL 8R/VV5YyiEd7PTSXWTsAfCOkVbOI+Me37VJ47GVL2aT90YluKxz2LI+zA3lznXt8085q TrvZ+uSDIkgeLOsdsbUH4/AYg3V303iEwEtZ/y3RTzVJDNV1zjbWBSaC/U/VLjI0ziQ5 QZQmWU9Hyuj+LxMTDcw4V56IB3pGcedN4ySCOfjyovmjKoyGCKdlkTmtgjc1p1Cl3RID 0+ZA==
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=4LhqTyNArP25VUxVjib5mPxzI6yRiAR1RZWt9WIY7bI=; b=ja9sAWGPMGSRD44qza2BpQ5Sns2NlYnN668fw0+GNJpM6J6+nuOPkNCW8GkcP0jwzO yUb/ej4+5g/4klYFDcZqAT1+IUa469gk5zUSZk+aA68ZSYdiO+TbceQ3R1Eq2BLKOxEc ++TqGyb3SBkP8+CYZ0+0N/68pMhwIB4UD7+5kown+8D9AVSStZwc5ME0dDBelGdObsOu US2XzZUCxMF2ylVOEIYR1/Qj3ffz+bX2fvdQHAK+wF9689x/scDnVCVptagCfw80QCoB 9XF9/MVgjT+N8e6qYWXO7oyePUZzGwZNa7R5dgrMTtynjI+CydxfRpjps0hpbwceqMET Mj/g==
X-Gm-Message-State: ALQs6tDfZYkEpTwwlWrH6Dba5jdE8GaXDrv58z5Akr4V7JQ1qjumpPzd 74ILKkhnX1UNTM67FSgiIPS/V/LXfKgXid5Y81uqbw==
X-Google-Smtp-Source: AB8JxZp0grObt57Q4qy0zkkdat01jLD0pyS6wStwiZ6bqgqa62fHU5aeMOCUWKJ5VQxLtN3Wm1spCUJjsvPv/qD8vyc=
X-Received: by with SMTP id b66mr9717442wmd.108.1525196527073; Tue, 01 May 2018 10:42:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 1 May 2018 10:42:06 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Tom Herbert <>
Date: Tue, 01 May 2018 10:42:06 -0700
Message-ID: <>
To: Dino Farinacci <>
Cc: Tom Herbert <>, "Joel M. Halpern" <>,, 5GANGIP <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: Problem Statement]
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 May 2018 17:42:12 -0000

On Tue, May 1, 2018 at 10:31 AM, Dino Farinacci <> wrote:
>> I think you've misunderstood my position. Caches are _very_ important
>> to eliminate the cost triangular routing (latency, average path load).
>> This reduces latency and reduces average load on ILA-Rs. But, and this
>> is the critical part, caches are only an _optimization_ in ILA. That
>> means if the cache is rendered ineffective (like by a well crafted DOS
>> attack) then the only effect is that the optimization is loss (i.e.
>> greater latency due to triangular router)-- this is quantitively the
>> worst effect of the attack on an ILA cache. This can be contrasted
>> that to LISP where the worst case effects of a DOS attack on the cache
>> is loss of service for users (infinite latency since packets can be
>> dropped or indefinitely blocked on a cache miss).
> Note in LISP, most of the time, prefixes are put in the cache. For ILA its mostly /128 host routes. And note, when an LISP ITR gets a Map-Reply, it can elect to put coarser EID-prefixes in the cache versus more specifics. Or, not elect to put anything in the cache and forward to PETRs (the same as your ILA-R routers) at the expense of suboptimal paths.
> There are many options in LISP prevent DoS attack cache attacks. I don’t think that is true when caches are used in ILA.
That is correct. For ILA I would like to have a normative description
of how the protocol is intended to deal with DOS attack. IMO, when
someone asks what the DOS mitigation of a protocol is the answer
should be clear and concise.


> Dino
>> Tom
>>> Yours,
>>> Joel
>>> On 5/1/18 12:37 PM, Tom Herbert wrote:
>>>> On Tue, May 1, 2018 at 9:10 AM, Joel M. Halpern <>
>>>> wrote:
>>>>> Three reactions, all personal opinion (in case someone thinks my having
>>>>> helped chair the BoF is in any way relevant; it isn't):
>>>>> 1) If ILA-Ns do not have caches, the ILA-Rs will become hot-spots in the
>>>>> network.  Yes, you have provision for multiple of them sharing load.
>>>>> However, if that sharing gets to be a significant percentage of teh
>>>>> routers
>>>>> in the network, then there is no point in having bothered with ILA, you
>>>>> are
>>>>> just routing on the SIR.
>>>> Joel,
>>>> If you provision a network (or any system really) based on an
>>>> assumption that caches will always attain some hit rate this is a
>>>> fundamental mistake. One of the goals of a DOS attack would be to
>>>> drive the hit rate to zero in which case someone will be in a world of
>>>> hurt. Caches and DOS are a hard mix to contend with in nearly any
>>>> context, that's why it's much better to view caches as an optimization
>>>> rather than a requirement. They can be used to alleviate load, but
>>>> that cannot be relied upon.
>>>> I would also point out that caches only make sense as internal devices
>>>> for intra domain communications. This does not make sense for edge
>>>> routers that would need to create a working set cache for any
>>>> aribtrary load of traffic from the Internet.
>>>>> 2) As far as I can tell, when some ILA-N have caches, the ILA-R have no
>>>>> way
>>>>> of knowing whether the ILA-N have caches or not.  I can understand what
>>>>> happens if all ILA-N in a network have the same cache state (either they
>>>>> all
>>>>> have caches or they all do not have caches).  But I do not know what
>>>>> behavior you expect of an ILA-R if the ILA-N are not uniform. Given the
>>>>> hot-spot issue above, I think you need to really explain why ILA-N would
>>>>> not
>>>>> ahve caches.
>>>> ILA-Rs and ILA-Ns communicate via ILAMP protocol. That can include
>>>> capabilities description.
>>>>> 3 - Minor) Your usage of "sharding" seems odd.  You are simply dividing
>>>>> the
>>>>> domain into address blocks, and distributing responsibility for those
>>>>> blocks
>>>>> separately.  In other contexts, sharding seems to be used more generally
>>>>> for
>>>>> having subcollections of the data which can be moved around.
>>>> Sharding is a database term that describes partitioning of the
>>>> database into smaller chunks for manageablibilty. That is what is
>>>> happening here (literally in the implementation since we are use a
>>>> database backend).
>>>> Tom
>> _______________________________________________
>> 5gangip mailing list