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

Tom Herbert <tom@quantonium.net> Tue, 01 May 2018 18:44 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 5395012EA76 for <ila@ietfa.amsl.com>; Tue, 1 May 2018 11:44:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
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=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 OiqRAUs94sKR for <ila@ietfa.amsl.com>; Tue, 1 May 2018 11:44:23 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3CEDD12E9D9 for <ila@ietf.org>; Tue, 1 May 2018 11:44:23 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id a67so11382611wmf.3 for <ila@ietf.org>; Tue, 01 May 2018 11:44:23 -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:content-transfer-encoding; bh=/fWLTZYI1/Yh2ECBGuBfBvIbnlm/ixqpJHOi/3KT+Og=; b=IKIJYZpKkwTd/e+1+44RLvZjE0YcZ3MjVPH9WIrUNNWTYQUA+E3iVVPHtaI1uoGHGy SJnDoPBknIsVuUYjU79D/Q+vE4dV9rW12f31tj6hScB8IXfGw6/tLzTdMSVa8+tvL1fV eppeJWDclAXCaocEqIYS+cN5IMTNINLvmNJGstQqef6BqOLvVQXOkACz1Pg4e3seg3r/ 2RHFp7bviE6L6dHyXVXI32DUKT3befHfBJKh6WC1s3N64R527jIakXg7GG+xN/NARQpg 16YjKUge/rqfQP4lF8KfOEBMB7crwFi923ojUuGQGuvXrwh0rispBP5iP/h/nlGpL/2e qkXA==
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:content-transfer-encoding; bh=/fWLTZYI1/Yh2ECBGuBfBvIbnlm/ixqpJHOi/3KT+Og=; b=iqt7Fts0HYu0LiegIGoF3Fi06e5W4kgOHjPIctNBEXDwCH7qsmizSXBgqnXopIDvr3 voh63XuwkuTQMfsN5cbHyIW8cCukUNv8uavNJ9j8jfgo4Ar6avNZBL0y9Jl20VX6T8ka AGd7CHE6LOFWpt2dRw30Xy1F9+Vtk1/H7CvxMvYfAZygjwOCet5JDAQp0tcfWUOHpedb pGSDxA42+ddqwaYTou18Pu+NYLtecxn67tVlope2lQbyUMjGL1YdQYXwLxRRyevPhe4t FPOssYfJHJdfWcO6wyVLgO1ISYMVwNuoCHoaz0o0c84EvIK+stEwwHVkdpftHwrREFsm WeDA==
X-Gm-Message-State: ALQs6tCI0xOiKdmh7l5WWLmi1/4zb6It3124LTR3qjdtb4tHxK2JlS++ 6gbLecvq0RHimiS/Toq6roiKcWNaPjaswCMo1bUXXg==
X-Google-Smtp-Source: AB8JxZoNNNmFhaV8CQImUNra5an+kMPBeHq5h9yvU4g/K7gP0bIIoyo8/514Xprctfk9xLRxDjHhH8TBtLRu1p0824c=
X-Received: by 10.28.124.10 with SMTP id x10mr9581415wmc.59.1525200261645; Tue, 01 May 2018 11:44:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.128.227 with HTTP; Tue, 1 May 2018 11:44:21 -0700 (PDT)
In-Reply-To: <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com>
References: <CALx6S37_oce-S0pEUgB8CpkWemcHhrb4HoDXUfPHZMGiokCqcA@mail.gmail.com> <04561B6C-E280-4EE0-B789-3880C8B69A08@gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 01 May 2018 11:44:21 -0700
Message-ID: <CAPDqMerAV2SRRPGiU9UpsRkzZ5fOwsKNYM2+K1HsPysgXe4Lgg@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tom Herbert <tom@herbertland.com>, ila@ietf.org, Behcet Sarikaya <sarikaya@ieee.org>, Christian Huitema <huitema@huitema.net>, Dirk.von-Hugo@telekom.de, 5GANGIP <5gangip@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/w--HALQpR1J1p8subEIANf6_75s>
Subject: Re: [Ila] [5gangip] ILA forwaring [Was Re: 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 18:44:28 -0000

On Tue, May 1, 2018 at 10:25 AM, Dino Farinacci <farinacci@gmail.com> wrote:
>> 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?
>
That are host routes in the local ILA-R routing table.

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

Yes. It's already common technique with things like load balanceres
that on routing to distribute packets.

>
> Dino
>
> _______________________________________________
> 5gangip mailing list
> 5gangip@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip