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 >
- [Ila] Proposed charter Tom Herbert
- Re: [Ila] Proposed charter Alexandre Petrescu
- Re: [Ila] [E] Re: Proposed charter Bogineni, Kalyani
- Re: [Ila] [E] Re: Proposed charter Alexandre Petrescu
- Re: [Ila] Proposed charter Mark Smith
- Re: [Ila] [E] Re: Proposed charter Tom Herbert
- Re: [Ila] Proposed charter Tom Herbert
- Re: [Ila] Proposed charter Tom Herbert
- Re: [Ila] [E] Re: Proposed charter Alexandre Petrescu
- Re: [Ila] Proposed charter Dino Farinacci
- Re: [Ila] Proposed charter Mark Smith
- Re: [Ila] Proposed charter Dino Farinacci
- Re: [Ila] Proposed charter Alexandre Petrescu
- Re: [Ila] Proposed charter Tom Herbert
- Re: [Ila] Proposed charter Dino Farinacci
- Re: [Ila] Proposed charter Mark Smith