[Ila] ILA forwaring [Was Re: [5gangip] Problem Statement]
Tom Herbert <tom@herbertland.com> Tue, 01 May 2018 15:54 UTC
Return-Path: <tom@herbertland.com>
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 7159412DA4B for <ila@ietfa.amsl.com>; Tue, 1 May 2018 08:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 knl02cELHU2N for <ila@ietfa.amsl.com>; Tue, 1 May 2018 08:54:25 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 1709512DA70 for <ila@ietf.org>; Tue, 1 May 2018 08:54:25 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id z75so9153275qkb.6 for <ila@ietf.org>; Tue, 01 May 2018 08:54:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ffjfMUlH0BiysY0skgQiaqirNV9ZeBk1Kg4pji8hpiY=; b=gJEKsCHmL3SiAKHYUTCqEhv8RCLq+vb4Tv05o26PAYUi/RIGIZikiX1qIRgAiNjfyM ec44BWm2dl0X4zstLJiI1TwcylMpeO1mUwUulrhyXEP92TCTuhdtsNpw9kGWZm66rGTS RSzasYbCb+tgezTTHrPRCzDT+9z52bMdB35NQZadLlp0PkMUSybJEpjuRkPOur5EgTa2 +vSQFTIJTxL/YEJH5Vhet4B9JTwdTYwkue+ygo0udOJEifdy27IaTMMc2NdSk7OnpGIO DGLKM14LibVU63RklnCC+GWtNFbkp1CZLIqKgqYdHpVhWidY55cdkOrh3ECAXjZonWJN Ehrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ffjfMUlH0BiysY0skgQiaqirNV9ZeBk1Kg4pji8hpiY=; b=OLRmp++9rW7vifcsLL3twF9Eopx0o0ipO8LD2A9ZggUN0HfNQaAb0htofNlvXKdsqT kgemT/kXBE+/NiGBzBc99jcrDpdo56F86s1SZUn0rstCtjdgIaTNDMQedscy6PRa0I7g ZWivAnLfRZwtcpZ+REXTrXazwZG9eJqUghvahF61enJHG5gZfunATqgR1fJh2WlTLvbc hyDKBFHJPKMC6whz0ZdzPjfDJIzVUkKd3UGkSLD3x8USlDJoaJej6FbdSzn4d32brW6a h1OkVc8CrxZ7zPK4Tqxk9BjSu9qI1OxdJhyi0GsXRzxRG/oKb95ZAjMyRaPzSvCsFI8N 7zDw==
X-Gm-Message-State: ALQs6tC26FrxGmumSlfEV3nJF07+Ab0vNw1fFsSi8XOvS1TF4yPnT7u6 80EDPBlnFVDTMUfoSgASEKRw7LisMGTWshtqiC1bFQ==
X-Google-Smtp-Source: AB8JxZpgJFlVIvg1E3fM7Ynao1lDVMrgvIuHoJ20/PtBFa1/U4Exv8ickwkDQD8VR9OEC7lsjZIP2QvLI9q6aj1xU8I=
X-Received: by 10.55.194.13 with SMTP id i13mr12589210qkm.311.1525190063888; Tue, 01 May 2018 08:54:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.66 with HTTP; Tue, 1 May 2018 08:54:23 -0700 (PDT)
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 01 May 2018 08:54:23 -0700
Message-ID: <CALx6S37_oce-S0pEUgB8CpkWemcHhrb4HoDXUfPHZMGiokCqcA@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tom Herbert <tom@quantonium.net>, 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"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/CAoP_4igbvPjzwJueNOBMkqu-8U>
Subject: [Ila] ILA forwaring [Was Re: [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: Tue, 01 May 2018 15:54:27 -0000
Dino, > I don’t want to look at code. I want you to explain clearly how a cache misser gets the RLOC. What if the identifier is not in its shard? > RLOCs don't exist in ILA, that is a LISP term. > You are missing the point. Forward to where? How? > I will try to answer your questions in as much detail as possible. Here are the example cases that illustrate operation. Case #1: A network has a single SIR prefix and one ILA-R and some number of ILA-Ns. The ILA-Ns do not have a map cache and are only used for SIR to ILA transformation. The ILA-R advertises the SIR prefix in normal IP routing. It is the router for the SIR prefix. Packets destined to an address with the SIR prefix are thus routed the to ILA-R. Mapping entries are realized as hosts routes in the ILA-R where the destination host is composed of the SIR prefix and identifier. When an ILA-R receives a packet it performs a route lookup. If the returned route is an ILA route then the ILA transformation is performed where the SIR prefix is overridden with the locator indicated in the route. The packet is then forwarded back into the network. Normal IP routing forwards the packet to an ILA-N corresponding to the locator (each ILA-N is assigned a unique locator and routing is configured so that all packets with the locator prefix in the destination address are forwarded to the ILA-N). At the ILA-N, ILA to SIR transformation occurs so that original packet is restored. The packet is then forwarded by the ILA-N to a downstream destination (e.g. a UE). If an ILA-R receives a packet and it finds there is no route for it then it drops the packet. So if no ILA mapping exists for an identifier address then the packet is dropped. The ILA-R contains all the mappings for the ILA domain, if does not need to ask someone else if it doesn't find a mapping. ILA-Rs are not map caches. Case #2: A network has a single SIR prefix and multiple ILA-R and some number of ILA-Ns. The ILA-Ns do not have a map cache and are only use for SIR to ILA transformation. This is the case where ILA-Rs are replicated for load and availability. Each ILA-R advertises the SIR prefix in IP routing for the network. Routing techniques of ECMP, shortest path, etc. are used to route packets to the "nearest" ILA-R. Packet processing at each ILA-R is the same as described in case #1. Case #3: A network has a multiple ILA-R that shard the mapping entries and some number of ILA-Ns. The ILA-Ns do not have a map cache and are only use for SIR to ILA transformation. The low order bits of the SIR prefix contain a shard index, the high order bits are common. In this case the mapping table is not contained a single ILA-R, it is sharded across some number of them. This might be done because the table is too big, or for geographic locality, etc. Each shard is associated with an index. SIR prefixes are composed of a common prefix and the index in the low order bits (for instance index could be eight bits). Each ILA-R then advertises its SIR prefix that includes its index in IP routing. An ILA-R can also serve multiple shards so it may advertise multiple prefixes in routing. Each shard may also be replicated per case #2. Packet processing at each ILA-R is the same as described in case #1. * Note that none of these cases so far require a mapping cache. These work for all packets regardless of the source. The sender may be local to the network, or may be a host on the Internet. Case 4: Map caches are enabled on ILA-Ns. The map cache is implemented as host routes in an ILA-N similar to ILA-R routes. When a packet is sent by a downstream device (e.g. a UE) it traverses an ILA-N. The ILA-N performs a route lookup on the packet. If an ILA route is found (a map cache hit) an ILA transformation is performed an the packet is forwarded directly towards the destination. If there is no ILA route (map cache miss), then another route is found possibly the default route (remember these are just normal route lookups). The packet is forward per the route and since it still has a SIR prefix in the destination address it will be forwarded to an ILA-R as described in case #1. The ILA-N does not send a mapping request and does not remember the destination, it just forwards without incurring any additional delay. When ILA-Rs receive packets they transform and forward them as described above. It MAY also send an ILA redirect. An ILA redirect can only be sent to an ILA-N that is in the local ILA domain. To do this the ILA-R performs a reverse lookup on the source address of the received packets. If the lookup returns an ILA route then that will contain the locator corresponding to the ILA-N for the sender. A redirect message is sent the locator using ILAMP. This contains the destination and the locator. When the ILA-N receives the redirect it instantiates the routing table with an ILA route. Subsequent packets then can use the route so that packets are router directly thereby eliminating triangular routing. There are other details about managing the ILA cache that are described in draft-herbert-ila-ilamp-00. Tom
- [Ila] ILA forwaring [Was Re: [5gangip] Problem St… Tom Herbert
- Re: [Ila] ILA forwaring [Was Re: [5gangip] Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] ILA forwaring [Was Re: [5gangip] Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Behcet Sarikaya
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dino Farinacci
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Alberto Rodriguez-Natal
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Alberto Rodriguez-Natal
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Dirk.von-Hugo
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Joel M. Halpern
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Lorenzo Colitti
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… FIGURELLE, TERRY F
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Lorenzo Colitti
- Re: [Ila] [5gangip] ILA forwaring [Was Re: Proble… Tom Herbert