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

Dino Farinacci <farinacci@gmail.com> Tue, 01 May 2018 17:27 UTC

Return-Path: <farinacci@gmail.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 592DC12E8CE; Tue, 1 May 2018 10:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 FUcgXSglMZSy; Tue, 1 May 2018 10:27:01 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 DD13B126C89; Tue, 1 May 2018 10:27:00 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id q6-v6so15335523qtn.3; Tue, 01 May 2018 10:27:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S+CG0bRqDI4PUUyp+sLvAekE3eODDX7zRhExrLRNe3Q=; b=Kn3UV26hPHKWe0a30KiEUgXOjkJcpWrXZ+xGXVETVlsdOP4URirWG+mLcgZo7E4j6B QVipdpd+30T4t0kMMNSaYlfKqJOHFWdKYkT1rofl3fTTtxDVsFfNf0bOf5Wdr9GUL+mk Fsbj8WIo75WO485aTW5CwlNo93h3hQ0Ysm+a5X+2tLL4xfaXlAhRrzaCuUdlCT+Ei/Xp xDEvQ7EeEZ6T2gEJkujTsfKeuE6u+AcrGTYzrFQh1JMIDhw4IrxzQMnDlWQ/fbiZzwe+ K451sFxffr66vXIc1/PPz9/UhKsdoDTlICZwsgNqz5m92wG2rkK1BxXHE4WQZzRAdjPQ 7/xQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=S+CG0bRqDI4PUUyp+sLvAekE3eODDX7zRhExrLRNe3Q=; b=YXvDiWKKaIpT+/vZVrvF0qjqRoeE0udQzQP6J8UxpSgn/NpaDnYVvzhRT4Ccf71ypf KbhRKX2ccO4Lp/uDropGpeMFkWGtoNU6cIENICBB4fdvCeK9/zeRLz2pJir8aPX8eveQ Fxq/DGG7hC+Nt2kT98l1mhZ8OtHTuzo6ww4gi1GTDJuEtCnLe0saUbeTT/rwuO8nupT3 rAhxbL3TbIkBLsu70eEqJNqMZCe6ylYiub0CzF7nhsQRH/UPdTTu/mTkTfXItihww97v jvGNgaHokoi+P6sYDXxn06ojgKpLnmKNRgU3u3Ww964RCZhX73GsWDmNKjtjjKQ2y3Il xSHg==
X-Gm-Message-State: ALQs6tDg3/6gCCZZJixKHrWwgX1UNzKfInPSdcLtTTlOJadKF+l4dsuI qJmmhHcHV+tUY3QzfUsJRsQ=
X-Google-Smtp-Source: AB8JxZouj31xbyVnKKFLoHV/xAuwt0jZm6X9Uy7eIQHDBTHNcCPS6HJ4B0ImZ0paa8FWJYCWMSmL3w==
X-Received: by 2002:ac8:2916:: with SMTP id y22-v6mr14894809qty.18.1525195619675; Tue, 01 May 2018 10:26:59 -0700 (PDT)
Received: from [10.207.57.221] ([184.169.45.4]) by smtp.gmail.com with ESMTPSA id e56-v6sm8698475qtc.61.2018.05.01.10.26.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 10:26:59 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CALx6S37_oce-S0pEUgB8CpkWemcHhrb4HoDXUfPHZMGiokCqcA@mail.gmail.com>
Date: Tue, 01 May 2018 10:25:46 -0700
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-Transfer-Encoding: quoted-printable
Message-Id: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com>
References: <CALx6S37_oce-S0pEUgB8CpkWemcHhrb4HoDXUfPHZMGiokCqcA@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/FeEfezRU6Fcf6b1FY8s-gR_Ct6U>
Subject: Re: [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 17:27:03 -0000

> I will try to answer your questions in as much detail as possible.

Thanks for more details.

> 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

What do you mean by realized. Are host routes storedin ILR-R routers via a push protocol like ILAMP? You are going to push all host routes for all ILA-N nodes in the Internet?

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

That is not clear for case #1. Answer my above question first.

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

Okay, so the scale of the underlay depends on the number of SIR prefixes injected into the routing system. When using sharding, it could be a lot. This model is kinda a hybrid overlay/underlay where the underlay needs to take part in make packet forwarding work. So be it.

Dino