Re: [Ila] [5gangip] Problem Statement
Tom Herbert <tom@quantonium.net> Fri, 27 April 2018 18:37 UTC
Return-Path: <tom@quantonium.net>
X-Original-To: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE3B1200C5 for <ila@ietfa.amsl.com>; Fri, 27 Apr 2018 11:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbznUqcGau9A for <ila@ietfa.amsl.com>; Fri, 27 Apr 2018 11:37:11 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735C2124205 for <ila@ietf.org>; Fri, 27 Apr 2018 11:37:11 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id g21-v6so2637455wrb.8 for <ila@ietf.org>; Fri, 27 Apr 2018 11:37:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/mc0DPZcuGibmiulwjf4yk9yXZQOcToy7YiWFn8mQKY=; b=qx0tjFLeZHUcMlatuEdrsSHyNSiWjTOtjXHZP99FRCNBjP53nHR8Wt+8XrvueWGAW8 5WzFxbf7uI0FF189x1pfevhE06EY/rxMBTAyFN2jK7PJrOi7NM7S6d+pPQjRqj+CR4hk zNEK8t5viTD7Xwg0CMrTzXkp42kDCPJ4u6Hmlbj4CkQmJqlEOoCPo+9g9EtwPdLbn5+Q FUErNhUuYE7PWb6x08TW26bmbIIVEj/gqAjJWxPZ7BVcRo8xS4Rz/0/CKhzGlmQwyIK/ KRcqPJY6Dvo+TVUvNfvXhte4V8eVfbIzbvvJ1THfzhn8OqRxOEUwZeiE/3OsLIj2WoV1 iomw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/mc0DPZcuGibmiulwjf4yk9yXZQOcToy7YiWFn8mQKY=; b=i2evQTlffrmKftgZvE2T4x+gOG2YXmK3USfbCzyhTvl0R0HPzJyD5MwaNTmFeFL57/ v0tj1+SQ2IgAY+W/iKq2dvuNVXA9xwCvZkOR2Qhiftm2LlKxgc0Urt0MSYa54vIDIQMj q5gbg3kwFcAC/5HeEoRXguUZuze+9FFxKcj072V5Uy2jVj/Lvu/VveronkeGqclx2DqM cdx0P9S6UsGqqW8ql3mojblAHQtPzSae8JQzG7wk7bmnMcwsqBGoEMUIfW8Ai3TaqnnD DmwaIBljvRDkpHfcbF9tGzBSX9462223F2LvuFJMZd6xA2rNsoBzYXxVnVrwFCUDjQyd Ul+w==
X-Gm-Message-State: ALQs6tDePBYQjU3ut6rURkWFlexvUUc9vM8klOzsY5fenP2a6cNJ6aOr FYmeMn0pEo8bghozP8HZY4R4B5xpZBPmEogNDhSIsw==
X-Google-Smtp-Source: AB8JxZqyLVZ9zsC/3AFsDZXVaebIwB3JTBRmHBaAKr1urox4uYD0dgUae5T7Y3DHXOEU2fd+nROkhh3EZ06pycSbCAo=
X-Received: by 2002:adf:e181:: with SMTP id k1-v6mr2704791wri.111.1524854229813; Fri, 27 Apr 2018 11:37:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.128.227 with HTTP; Fri, 27 Apr 2018 11:37:09 -0700 (PDT)
In-Reply-To: <9C0497E2-017A-471B-8B73-70CD335A7CFD@gmail.com>
References: <CAC8QAcfTZbSmnhpc-s_e=e4Kg_SO7bUQ8gK64=nAGsxv9Y7rjw@mail.gmail.com> <CALx6S37wVQ5FGvqikbFUtLK3LKcp7fKsLCsgp5yrMnTQ52s2=w@mail.gmail.com> <347F486D-0F7B-45D9-92B6-3AFE10B0550E@gmail.com> <CAPDqMeo-+CHxHr0dVNmc=23T+EMOjrL9Stcxv0JGjY1UH0QU2g@mail.gmail.com> <9C0497E2-017A-471B-8B73-70CD335A7CFD@gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 27 Apr 2018 11:37:09 -0700
Message-ID: <CAPDqMepRMFn2xNcdezetZxo591BJkahTBJ2QU_oTN2Mt8OMnZw@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tom Herbert <tom@herbertland.com>, 5GANGIP <5gangip@ietf.org>, Behcet Sarikaya <sarikaya@ieee.org>, Christian Huitema <huitema@huitema.net>, Dirk.von-Hugo@telekom.de, ila@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/ZreiiRm_0Zvpv6ywE9Zy9dEwfR4>
Subject: Re: [Ila] [5gangip] Problem Statement
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2018 18:37:14 -0000
On Fri, Apr 27, 2018 at 11:21 AM, Dino Farinacci <farinacci@gmail.com> wrote: >> >> Yes,you can differentiate them. ILA never drops of blocks packets >> becasue of cache miss; LISP allows that at least in certain >> configurations. So the worst DOS attack in ILA results in sub-optimal >> routing, worst case in LISP is indefinitely blocking packets. > > What does an ILA router (one that maintains a cache) do when there there is a map-cache miss? > ILA routers (ILA-R) are not caches. They contain their shard of the mapping system. ILA forwarding nodes (ILA-N) may have a cache. In the case of a cache miss the packet is forwarded. It will go to an ILA router that can perform ILA transformation. The ILA router may also send back an ILA redirect to the forwarding node to populate the cache so that it can perform the transformation on subsequent packets. ILA forwarding nodes never drop or block packets because of a cache miss. Tom > Dino
- Re: [Ila] [5gangip] Problem Statement Tom Herbert
- Re: [Ila] [5gangip] Problem Statement Dino Farinacci
- Re: [Ila] [5gangip] Problem Statement Tom Herbert
- Re: [Ila] [5gangip] Problem Statement Dino Farinacci