Re: [Ila] Proposed charter

Mark Smith <markzzzsmith@gmail.com> Sat, 03 February 2018 23:31 UTC

Return-Path: <markzzzsmith@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 0136D1204DA for <ila@ietfa.amsl.com>; Sat, 3 Feb 2018 15:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 6xoYvxgT6noz for <ila@ietfa.amsl.com>; Sat, 3 Feb 2018 15:31:10 -0800 (PST)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 60CC9124217 for <ila@ietf.org>; Sat, 3 Feb 2018 15:31:10 -0800 (PST)
Received: by mail-vk0-x229.google.com with SMTP id q62so15659093vkb.11 for <ila@ietf.org>; Sat, 03 Feb 2018 15:31:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ce2VWe8Gsxn4B1mqk5FbXcIKGB/40OknC3Ods2mWz28=; b=XIRgIvD6ILyEGckZ30r2C1RwfQFlzDAut5iKG18rtK1KfzaejVWyRWr91prpK525Ws apuSNXfly1zlr5Bo6WgA7FabM82kEAP9CowMtEAhvRt8Er1uoJ8+/DK9OZq2+QRial5P B3n1hXG+GgTUoM27OApaPLRz/Hy2m8n0L2uhS2aYhf8iUAMoMg/w4P23zjFnB2yNZh3Q 0SHo/KCMMsqRVe6AnTUI4EaSn+Uc7nr2lSxbq+CT4qb/vRG9liXyDpeZ/5tFP0MGvdLN cje9SOm3Xhv1JNmza7yNbPq/XcknqiRZF4MqNeOtnezXSgVDD2CZzmukquOIh07KHwCL nWDg==
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=Ce2VWe8Gsxn4B1mqk5FbXcIKGB/40OknC3Ods2mWz28=; b=sUIGDTcT7OT61AxgyZIUZd3w2HyMH66xrwj4MY/Y3RM0LFUUh/Zw4zz0cL2wkzE/nN t5DRThY8ZUrPrIyz0MyqhIWZ5BPudOYeaqwZJMJ8TfmLY0tGZoRM4l8BTKPRJ3/B3yvn 6mmdN1K56ZDb5fqbOpWXB3j9g6LmVy9wpwvft3VOl6YK+MMok0LUodGu7tTiq0L4oOK4 A3i7VietmJ47LnlaTc8wVdrPMi/cvt9wQX9GArn3QmPmqZTxJBaOaBTjhzY3Uk5kC4RT ZKEF7D3GyJMjx61gAFrL/Gl9nUm/KUSmJCF7FHU2Cx8YEk9W3t6uO/ZMIAyz9U2OJbyf Qa6w==
X-Gm-Message-State: AKwxytfKLkePefH/iv2X2mV1HTvJRd8Zw3RThvcP/IpAjRroWD308KLw AcFX5oMY6hbsAbsPD/oRtooPbBqz+/p3d2xwTnI=
X-Google-Smtp-Source: AH8x227nPu2KAOuKRVcikGPT0Y1K7XONOd9ir0L5AyqvZmD1eK1rWNBJKyJuOxTKHuH9NmgB2fZj7hXwPH/Gl9i4A3M=
X-Received: by 10.31.196.131 with SMTP id u125mr31212105vkf.158.1517700669089; Sat, 03 Feb 2018 15:31:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.3.248 with HTTP; Sat, 3 Feb 2018 15:30:38 -0800 (PST)
In-Reply-To: <A370F7C3-383B-4591-8172-D13BD6283BB9@gmail.com>
References: <CAPDqMeqWDdqgrU4UrhCBo0W2kD4CODnPPNJHAC_8LrZXcaoJRw@mail.gmail.com> <372ebd81-b666-31bd-244d-57021d217e63@gmail.com> <CAO42Z2xWUGL1rpd+86rKz+DBuQht12ZKMv3hg9y30j_rOner5A@mail.gmail.com> <CAPDqMeq807+mCOMsDQ9CNtRURKT_nXH_JW1deKbvA9pAVZYOFQ@mail.gmail.com> <A370F7C3-383B-4591-8172-D13BD6283BB9@gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 04 Feb 2018 10:30:38 +1100
Message-ID: <CAO42Z2zNXZ1kZM35zpW=deAJsLhF9oF7eJ5TLQ6BcfpEAn5upA@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tom Herbert <tom@quantonium.net>, Alexandre Petrescu <alexandre.petrescu@gmail.com>, ila@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/XnR5wp_1LFBXnUlMEM5uGMd5rvQ>
Subject: Re: [Ila] Proposed charter
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: Sat, 03 Feb 2018 23:31:12 -0000

Hi Dino,

Sorry not to get back to you sooner.

On 19 January 2018 at 05:45, Dino Farinacci <farinacci@gmail.com> wrote:
>>> The ILA domain is effectively a virtual link layer or an underlay network
>>> for the traffic being carried between hosts outside of the ILA domain. As
>>> long as the ILA domain is perfectly transparent to the overlay network and
>>> its hosts, then what ever happens within the ILA domain doesn't matter,
>>> similar to how link layer compression, as long as fully and perfectly
>>> reversed, also doesn't matter.)
>
> Mark, it was interesting the way you worded this. I think of ILA and “its domain” as the overlay and once the originated packet is transformed, it traverses the underlay.
>

It has a few years since I read through Tom's initial ILA draft, and
I'd forgotten a fair amount, in particular about the ILA address
transform happening on the same device that originated the pre-ILA
packet.

The thing I remembered was that it could be described as
"encapsulationless" tunnelling, where tunnel end-points are
represented by /64s rather than /128s, and the address information
that is normally preserved in the inner packet header is instead
preserved in the ILA ingress and egress devices in the /64 mapping
tables. It isn't perfect tunnelling though, as the hop count, DSCP and
possibly the flow label field values are not preserved.

My default view of tunnelling is that it occurs somewhere within the
network.That means my default view of hosts is that they are simple,
meaning that they use the addresses they're given, the address(es) the
host has are the address(es) that are visible to applications and the
IP stack in the host below the application normally won't do anything
"complex" like ILA.

So from the perspective of the applications, ILA looks like something
that is occurring in the IP layer (either within the packet origin
device, or within a router along the path to the final destination),
and as an IP tunnel is a virtual link, and links appear below the IP
layer, that is why I described ILA as an underlay.

Regards,
Mark.





> Dino
>