Re: [Ila] Proposed charter

[Dino Farinacci <[e-mail]>]

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

But yes, you got it.

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

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.

> So from the perspective of the applications, ILA looks like something
> that is occurring in the IP layer (either within the packet origin

Right.

> 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

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

> 
> Regards,
> Mark.
> 
> 
> 
> 
> 
>> Dino
>>