Subject: [Ila] Second round draft charter

From: Tom Herbert <[email-masked]>
Date: Thu, 8 Feb 2018 16:03:40 -0800

Hello,

I Incorporated feedback from the first draft including replacing
"translation" with "transformation". Aldo, incorporated some of the
language from the BOF description.

Please comment!

Thanks,

Tom

------

Identifier-Locator Addressing (ILA) is a protocol to implement transparent
network overlays without encapsulation. It addresses the need for network
overlays in virtualization and mobility that are efficient, lightweight,
performant, scalable, secure, provide seamless mobility, leverage and
encourage use of IPv6, provide strong privacy, are interoperable with
existing infrastructure, applicable to a variety of use cases, and have
simplified control and management.

The use cases of ILA include mobile networks, datacenter virtualization,
and network virtualization. A recent trend in the industry is to build
converged networks containing all three of these to provide low latency and
high availability. A single network overlay solution that works across
multiple use cases is appealing.

ILA is a form of identifier/locator split where IPv6 addresses are
transformed from application-visible, non-topological “identifier”
addresses to topological “locator” addresses. Locator addresses allow
packets to be forwarded to the network location where a logical or mobile
node currently resides or is attached. Before delivery to the ultimate
destination, addresses are reverse transformed back to the original
application visible addresses. ILA does address “transformation” as opposed
to “translation” since address modifications are always undone. ILA is
conceptually similar to ILNP and 8+8, however ILA is contained in the
network layer. It is not limited to end node deployment, does not require
any changes to transport layer protocols, and does not use extension
headers.

ILA includes both a data plane and control plane. The data plane defines
the address structure and mechanisms for transforming application visible
identifier addresses to locator addresses. The control plane’s primary
focus is a mapping system that includes a database of identifier to locator
mappings. This mapping database drives ILA transformations. Control plane
protocols disseminate identifier to locator mappings amongst ILA nodes.

The goal of this group is to elaborate on use cases, problems, and
solution. The expected output is documents that specify the ILA data plane
and control plane. Similar to IP routing, different control plane protocols
may be defined for different use cases. This group will define at least one
control plane reference protocol.

The group will pay particular attention to privacy, secure, and scalability
characteristics of the solution. A goal of ILA is to facilitate strong user
privacy in addresses; this is achieved by purging IP addresses of hierarchy
that could be used to infer geo-location, and also by allowing applications
to use source addresses for different flows to prevent unwanted
correlations being being made by a third party . Also, the mapping system
contains personally identifiable information (PII) that can reveal user
identities or physical location of users, hence access to the mapping
system must be strictly controlled. The mapping system must be resilient to
Denial of Service attack. Scalability of both the deployment architecture
and mapping system is important since the number of identifiers in a
network is expected to be in the billions.

This group will try to reuse relevant technologies from existing mobility
and encapsulation solutions. It will also leverage recent work in scalable
distributed databases and key-value stores. The work produced by this group
may be relevant to DMM, nvo3, LISP, int-area, v6ops working groups in IETF,
as well as other SDOs such as 3GPP.

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 9 Feb 2018 01:28:53 +0000

Hi Tom,

Below draft looks fine as a starting point.
Few comments in-line [Uma]:

--
Uma C.

From: ila [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Thursday, February 08, 2018 4:04 PM
To: [email-masked]; Bogineni, Kalyani <[email-masked]>
Subject: [Ila] Second round draft charter

Hello,

I Incorporated feedback from the first draft including replacing "translation" with "transformation". Aldo, incorporated some of the language from the BOF description.

Please comment!

Thanks,

Tom

------

Identifier-Locator Addressing (ILA) is a protocol to implement transparent network overlays without encapsulation. It addresses the need for network overlays in virtualization and mobility that are efficient, lightweight, performant, scalable, secure, provide seamless mobility, leverage and encourage use of IPv6, provide strong privacy, are interoperable with existing infrastructure, applicable to a variety of use cases, and have simplified control and management.

The use cases of ILA include mobile networks, datacenter virtualization, and network virtualization.

[Uma]: Can you expand mobile networks term here. I hope you meant, cellular and wi-fi networks or anything else? Also please be specific on virtualization application..

A recent trend in the industry is to build converged networks containing all three of these to provide low latency and high availability. A single network overlay solution that works across multiple use cases is appealing.

ILA is a form of identifier/locator split where IPv6 addresses are transformed from application-visible, non-topological “identifier” addresses to topological “locator” addresses. Locator addresses allow packets to be forwarded to the network location where a logical or mobile node currently resides or is attached. Before delivery to the ultimate destination, addresses are reverse transformed back to the original application visible addresses. ILA does address “transformation” as opposed to “translation” since address modifications are always undone. ILA is conceptually similar to ILNP and 8+8, however ILA is contained in the network layer. It is not limited to end node deployment, does not require any changes to transport layer protocols, and does not use extension headers.

ILA includes both a data plane and control plane.

[Uma]: This need to be listed in the charter work items.

The data plane defines the address structure and mechanisms for transforming application visible identifier addresses to locator addresses. The control plane’s primary focus is a mapping system that includes a database of identifier to locator mappings. This mapping database drives ILA transformations. Control plane protocols disseminate identifier to locator mappings amongst ILA nodes.

The goal of this group is to elaborate on use cases, problems, and solution. The expected output is documents that specify the ILA data plane and control plane. Similar to IP routing, different control plane protocols may be defined for different use cases. This group will define at least one control plane reference protocol.

[Uma]: It’s good to be clear and explicit on the scope of the work i.e, with in a single administrative domain or across.

The group will pay particular attention to privacy, secure, and scalability characteristics of the solution. A goal of ILA is to facilitate strong user privacy in addresses; this is achieved by purging IP addresses of hierarchy that could be used to infer geo-location, and also by allowing applications to use source addresses for different flows to prevent unwanted correlations being being made by a third party . Also, the mapping system contains personally identifiable information (PII) that can reveal user identities or physical location of users, hence access to the mapping system must be strictly controlled. The mapping system must be resilient to Denial of Service attack. Scalability of both the deployment architecture and mapping system is important since the number of identifiers in a network is expected to be in the billions.

This group will try to reuse relevant technologies from existing mobility and encapsulation solutions. It will also leverage recent work in scalable distributed databases and key-value stores. The work produced by this group may be relevant to DMM, nvo3, LISP, int-area,

[Uma]: Would suggest to include RTGWG too, as solutions have implications on routing aspects.

v6ops working groups in IETF, as well as other SDOs such as 3GPP.

[Uma]: Would be good to start listing the main work items.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 15 Feb 2018 13:39:22 +0100

Le 09/02/2018 à 02:28, Uma Chunduri a écrit :
> *From:*ila [mailto:[email-masked]] *On Behalf Of *Tom Herbert
> *Sent:* Thursday, February 08, 2018 4:04 PM
> *To:* [email-masked]; Bogineni, Kalyani <[email-masked]>
> *Subject:* [Ila] Second round draft charter
> 
> Hello,
> 
> Identifier-Locator Addressing (ILA) is a protocol to implement 
> transparent network overlays without encapsulation. It addresses the 
> need for network overlays in virtualization and mobility that are 
> efficient, lightweight, performant, scalable, secure, provide seamless 
> mobility, leverage and encourage use of IPv6, provide strong privacy, 
> are interoperable with existing infrastructure, applicable to a variety 
> of use cases, and have simplified control and management.
> 
> and network virtualization.
> 
> *[Uma]: Can you expand mobile networks term here. I hope you meant, 
> cellular and wi-fi networks or anything else?

Side-note, at IETF a 'Mobile Network' is a network that moves, per RFC3753:

>    Mobile network
> 
>       An entire network, moving as a unit, which dynamically changes its
>       point of attachment to the Internet and thus its reachability in
>       the topology.  The mobile network is composed of one or more IP-
>       subnets and is connected to the global Internet via one or more
>       Mobile Routers (MR).  The internal configuration of the mobile
>       network is assumed to be relatively stable with respect to the MR.

For example, such a mobile network is what a user generates when s/he 
tethers a smartphone ('tethering').

On another hand, a 'mobile network' is what many people call in current 
conversation, including IETF WG email lists like v6ops, a 'cellular 
network'.

This discrepancy exist there for many years.  It seems to me more and 
more people tend to ignore that RFC terminology.

It deserves clarification, but maybe not in this Charter proposal.

That's why it's a side-note.

Alex
[...]

---

From: Tom Herbert <[email-masked]>
Date: Thu, 15 Feb 2018 09:27:12 -0800

On Thu, Feb 15, 2018 at 4:39 AM, Alexandre Petrescu
<[email-masked]> wrote:
>> "translation" with "transformation". Aldo, incorporated some of the language
>> from the BOF description.
>>
>> Please comment!
>>
>> Thanks,
>>
>> Tom
>>
>> ------
>>
> This discrepancy exist there for many years.  It seems to me more and more
> people tend to ignore that RFC terminology.
>
Alex,

Thanks for the pointer. It would seem that use of "mobile networks" in
the charter is not correct. Maybe this should be "device mobility" or
"mobile networking". This needs to capture the use case where it is
physical devices that are mobile, as opposed to virtual hosts moving
in network virtualization.

Tom

> _______________________________________________
> ila mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ila

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 22 Feb 2018 13:55:02 +0100

> in network virtualization.

I think 'mobile networking' is a good term for that.

As a side note, a private conversation about another matter, elightened 
me further on the term "Mobile Network"; it was used as early as 1993 in 
this context: "The techniques of encapsulation or source routing can be 
both used to deliver packets from the Mobile Network to wherever the 
particular Mobile Host is currently located." in a document that 
reflects perspective of IETF at that time.

Contrary to RFC 3753, the term 'Mobile Network' was used differently 
even at IETF.

Alex