Re: [Ila] Proposed charter

[Tom Herbert <[e-mail]>]

On Thu, Jan 18, 2018 at 3:21 AM, Alexandre Petrescu
<[e-mail]> wrote:
>
>
> 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.
>
Good point.

>> 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 :-)
>
No, it's not :-). Exposure of geo-location in IP addresses is a first
class concern for privacy so clarity is good here.

>
>> 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"?
>
I assume that is implied and required, but we can make it explicit.

Tom

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