Subject: Re: [Ila] Proposed charter

From: Mark Smith <[email-masked]>
Date: Sun, 4 Feb 2018 10:30:38 +1100

Hi Dino,

Sorry not to get back to you sooner.

On 19 January 2018 at 05:45, Dino Farinacci <[email-masked]> 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

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 3 Feb 2018 15:44:22 -0800

> transform happening on the same device that originated the pre-ILA

But I think you got it right.

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

But yes, you got it.

> IP stack in the host below the application normally won't do anything

All the ID/Loc split protocols we have been discussing (ILA, LISP, and ILNP) are all at the network the best they can be. Meaning where the transport layer pseudo-header checksum has to be dealt with, it is. For LISP there is no issue with that. For ILA, Tom did a neat trick to not require changes to the transport protocols. And for ILNP, it wanted to keep pure layering so required small changes to TCP and UDP.

But yes, at least for LISP, it can in the host or in the network. LISP is like dividing the network layer into 2 sub-layers. The top half sub-layer is EIDs that deal with the transport layer and the bottom half sub-layer are RLOCs that deal with the data-link layer. I think of ILA the same way, where the upper sub-layer deals with a locator that is called a generic SIR-prefix and the bottom sub-layer is when the SIR-prefix gets transformed to a routable locator. 

The former (LISP) uses an extra header and the later (ILA) does address translation. They both have pros and cons no doubt.

> that is occurring in the IP layer (either within the packet origin

Right.

> and as an IP tunnel is a virtual link, and links appear below the IP

There have been tunnels in the past (like cisco’s GRE) that treat that sort of tunnel as a virtual point-to-point link (and later a multi-point link). When you typed into the CLI “show interfaces” you would see that. And any interface-based feature could also apply to GRE features (ACLs can be configured on them, you can run routing protocols over them, etc)

LISP tunnels are not like that. They are more FIB resident. So you’d see them if you typed the equivalent of “show ip route”.  We call them “dyanmic encapsulating tunnels” so they are not virtual links. And they do not “realize a virtual topology” as some people like to refer to overlays.

> layer, that is why I described ILA as an underlay.

One could look at a packet and and its current instantiation of addresses to decide “where the packet is at this moment). So for LISP, if the packet has EIDs in them, they are on the edges of the network and are part of the overlay. Ditto for ILA Sir-prefixes. If you the packet has RLOCs in them, the packet is routable by a core network. Then the packet is in underlay (i.e. the BGP enabled capital-I Internet). Ditto for ILA when the locators have been transformed into routable prefixes.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Feb 2018 17:43:32 +0100

Le 04/02/2018 à 00:44, Dino Farinacci a écrit :
>>>>> 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.
> 
>> 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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 7 Feb 2018 09:18:12 -0800

On Wed, Feb 7, 2018 at 8:43 AM, Alexandre Petrescu <
[email-masked]> wrote:

>>>>>> then what ever happens within the ILA domain doesn't matter, similar
>>>>>> to how link layer compression, as long as fully and
>>> "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
> Also, translation of addresses that is not evil is the NPT: Network Prefix
> Translation RFC.
>

I like Mark's explanation that ILA is "address transformation" not "address
translation". Maybe "zero packet overhead" is  better than
"encapsulation-less" to capture the property that ILA doesn't require
anything additional to the existing IP header?

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 8 Feb 2018 09:17:05 +0900

> On Feb 8, 2018, at 1:43 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 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).

Yes it does. It puts a routing  header on. :-) 

The point is that it’s packet overhead no different than tunneling. 

Dino

---

From: Mark Smith <[email-masked]>
Date: Thu, 8 Feb 2018 12:26:22 +1100

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

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

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