[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