Re: [Ila] Proposed charter

[Alexandre Petrescu <[e-mail]>]

Le 18/01/2018 à 00:14, Tom Herbert a écrit :
> Here is a first stab at a charter. Please comment!
> 
> Tom
> --------------------------
> 
> Identifier-locator addressing (ILA) is a method of identifier/locator
> split used with IPv6 that eschews encapsulation. It is a means to
> implement network overlays based on translations between
> application-visible, non-topological “identifier”  addresses, and
> topological “locator” addresses. 

I suggest make it '"locator" IP addresses' instead of just
'"locator" addresses', to distinguish from geographical locator 
addresses like GNSS coordinates.  There _are_ Internet Draft proposals 
of putting GNSS coordinates in IPv6 extension headers.

> Locator addresses allow packets to be
> forwarded to the network location where a logical or mobile node
> currently resides or is attached.

Sprinkling "IP" somewhere in that paragraph would not hurt.

Or my mind is too twisted by the geographical discussions in vehicular 
networks :-)

> Before delivery to the ultimate
> destination or application, addresses are reverse translated back to
> the original application visible addresses. A database of identifier
> to locator mappings is maintained to facilitate translation.  Nodes
> can be mobile such that their identifier to locator mapping changes,
> but identifier addresses are persistent. ILA is similar to ILNP,
> however ILA is confined to the network layer, not limited to end node
> deployment, and doesn’t require extension headers.
> 
> 
> The goal of this group is to define and standardize the ILA datapath
> and control plane. The ILA datapath defines the address structure and
> mechanisms for translating between application visible identifier
> addresses and locator addresses.The control plane includes protocols
> to disseminate identifier to locator mappings. Similar to IP routing,
> different control plane protocols might be defined for different
> needs.
> 
> 
> The use cases of ILA include mobility, datacenter virtualization, and
> network virtualization; these will be elaborated on by the group.
> There are several benefits of ILA compared to existing solutions. ILA
> enables anchor-less mobility, benefits user privacy, and provides
> advantages over traditional encapsulation methods in terms of
> performance, efficiency, and compatibility with deployed networking
> hardware.
> 
> 
> Nodes performing ILA translation maintain a table of identifier to
> locator mappings. A node might might contain a full set of mappings
> (ILA routers) or a working set cache of mappings (ILA forwarding nodes
> and ILA hosts). Similar to IP routing protocols, different protocols
> may be employed for these two cases. There are three basic methods for
> populating the cache: push, pull, and redirects. The methods chosen
> must be considered in light of security considerations and potential
> for Denial of Service attacks.
> 
> 
> This 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 acheived 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 . 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. 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.

And, nothing about "this group will define the problem and requirements"?

Alex

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