[Ila] Second round draft charter

[Tom Herbert <[e-mail]>]

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.