Re: [Ila] Proposed charter

[Mark Smith <[e-mail]>]

On 8 Feb. 2018 03:43, "Alexandre Petrescu" <[e-mail]>
wrote:



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 <[e-mail]>
>> 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.


NPT still causes and suffers from a number of problems described in part 2
and 3 of this article.

https://blog.apnic.net/2016/10/26/trouble-nat-part-2/

Regards,
Mark.


[...]

Alex