Re: [Ila] Second round draft charter

[Uma Chunduri <[e-mail]>]

Hi Tom,

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

--
Uma C.

From: ila [mailto:[e-mail]] On Behalf Of Tom Herbert
Sent: Thursday, February 08, 2018 4:04 PM
To: [e-mail]; Bogineni, Kalyani <[e-mail]>
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.