Re: [Ila] Proposed charter

On 18 Jan 2018 22:21, "Alexandre Petrescu" <alexandre.petrescu@gmail.com>
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.

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 :-)

Yes.

In the IETF, whose primary protocols are the Internet Protocols, addresses
without any other qualifier are going to be Internet Protocol addresses.

The first sentence qualifies that IPv6 addresses are being discussed.

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.
>

I would suggest the use of the term "transform" to describe what is
happening, rather than "translate".

In English usage, I think "transform" is describing a perfect change from
one form to another. "Translate" is a word that that I think has a less
than perfect change from one form to another meaning. We translate between
spoken languages, because the change isn't perfect.

The process ILA performs is a perfect transform, once at ingress to the ILA
domain, into the ILA domain's address space, and a perfect transformation
back at ILA egress. If the transformation isn't perfect, then a fault has
occurred.

The other reason I'd avoid "translate" is that it in the IETF it carries
with it the association with IPv4 NAT and its drawbacks. ILA doesn't suffer
from these issues because of the full reversal of the address changes upon
egress from the ILA domain.

(So how come I don't like NAT at all, yet am ok with what ILA is doing? The
full reversal of the address charges at ILA egress is the first reason.
Secondly, within the ILA domain, the ingress ILA device is a host, that is
in effect originating the packet within the ILA domain it is sending to the
egress ILA device, which is also a host or end-point within the ILA domain.

The ILA domain is effectively a virtual link layer or an underlay network
for the traffic being carried between hosts outside of the ILA domain. As
long as the ILA domain is perfectly transparent to the overlay network and
its hosts, then what ever happens within the ILA domain doesn't matter,
similar to how link layer compression, as long as fully and perfectly
reversed, also doesn't matter.)

Regards,
Mark.

>
> 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
> ila@ietf.org
> https://www.ietf.org/mailman/listinfo/ila
>
>
_______________________________________________
ila mailing list
ila@ietf.org
https://www.ietf.org/mailman/listinfo/ila