Re: [Ila] Proposed charter

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 07 February 2018 16:43 UTC

Return-Path: <alexandre.petrescu@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 D397412706D for <ila@ietfa.amsl.com>; Wed, 7 Feb 2018 08:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 OS_vlgxzIYJB for <ila@ietfa.amsl.com>; Wed, 7 Feb 2018 08:43:36 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D744C124F57 for <ila@ietf.org>; Wed, 7 Feb 2018 08:43:35 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w17GhX9c032258; Wed, 7 Feb 2018 17:43:33 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A8A9220204A; Wed, 7 Feb 2018 17:43:33 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 96C0A202030; Wed, 7 Feb 2018 17:43:33 +0100 (CET)
Received: from [132.166.84.12] ([132.166.84.12]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id w17GhWtk006534; Wed, 7 Feb 2018 17:43:33 +0100
To: Dino Farinacci <farinacci@gmail.com>, Mark Smith <markzzzsmith@gmail.com>
Cc: Tom Herbert <tom@quantonium.net>, ila@ietf.org
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> <CAO42Z2zNXZ1kZM35zpW=deAJsLhF9oF7eJ5TLQ6BcfpEAn5upA@mail.gmail.com> <384E301C-228A-4A58-BDAB-A782248C1A49@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <655e51f0-2b25-c226-5f84-e907f4ef7001@gmail.com>
Date: Wed, 07 Feb 2018 17:43:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <384E301C-228A-4A58-BDAB-A782248C1A49@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ila/jEZ1jcmjybYbYZl6ree1pl4jVoo>
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: Wed, 07 Feb 2018 16:43:38 -0000


Le 04/02/2018 à 00:44, Dino Farinacci a écrit :
> 
>> 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.
> 
> But I think you got it right.
> 
>> 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.
> 
> Encapsulation-less is the right term. Meaning ILA puts no new headers
> on the packet. It changes the source and destination high-order bits
> in the packet. So the ID is perserved through the whole path.

I think encapsulation w/o new headers is better named 'address 
translation' rather than 'encapsulation-less' because there is no 
encapsulation at all.

There is also 'Routing Header' that does not put new headers on the 
packet. (the RH is there but the nodes rotate somehow the addresses inside).

Also, translation of addresses that is not evil is the NPT: Network 
Prefix Translation RFC.

[...]

Alex