Subject: [Ila] Proposed charter

From: Tom Herbert <[email-masked]>
Date: Wed, 17 Jan 2018 15:14:09 -0800

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jan 2018 12:21:10 +0100

Le 18/01/2018 à 00:14, Tom Herbert a écrit :
> 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
> 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

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

Alex

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

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Thu, 18 Jan 2018 12:33:01 +0000

Alex:

These two documents provide quite a bit of information on motivation and use cases.

https://datatracker.ietf.org/doc/draft-herbert-intarea-ila/

https://tools.ietf.org/html/draft-mueller-ila-mobility-03

Do you see a need for a requirements document? 

Kalyani

> -----Original Message-----
> From: ila [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, January 18, 2018 6:21 AM
> To: Tom Herbert <[email-masked]>
> Cc: [email-masked]
> Subject: [E] Re: [Ila] Proposed charter
> 
> 
> 
> 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.
> 
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> >
> man_listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__
> 0PomBT
> >
> Q&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBy
> nUdpT&m
> > =QFbhVSwTp0vBdJukrCZYLxKGnuv0-
> 1dvpqzf0bBDR88&s=Mcp9YoSv6tC1LlhwRyB087V
> > fnTMX0dRGIHf9LRZXP5g&e=
> >
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7
> UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs
> _YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=QFbhVSwTp0vBdJukrCZYLxKGnu
> v0-
> 1dvpqzf0bBDR88&s=Mcp9YoSv6tC1LlhwRyB087VfnTMX0dRGIHf9LRZXP5g&e
> =

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jan 2018 13:45:13 +0100

> https://tools.ietf.org/html/draft-mueller-ila-mobility-03

Good!  So the Charter should say this group is working on motivation and 
use-cases.  It currently doesnt.

> Do you see a need for a requirements document?

_a_ reqs document?  How many documents to provide is another issue. 
Maybe start with saying work on one document containing reqs, problem 
statement, motivation and use-cases.

'requirements'?  Yes, definitely list the requirements in some document, 
and not in the design document (too late).

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Jan 2018 00:19:23 +1100

On 18 Jan 2018 22:21, "Alexandre Petrescu" <[email-masked]>
wrote:

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.

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.

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

Alex

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Jan 2018 08:51:07 -0800

> use-cases.  It currently doesnt.
Hi Alexandre,

It does mention the use cases:

"The use cases of ILA include mobility, datacenter virtualization, and
network virtualization; these will be elaborated on by the group."

I think we want to be careful not to pigeonhole too much on one use
case and try to keep the protocol generic for broadest applicability.
Do you think we need more words here?

> _a_ reqs document?  How many documents to provide is another issue. Maybe
> start with saying work on one document containing reqs, problem statement,
> motivation and use-cases.
>
Agreed, one document with problem statement/motivation/use cases is
probably next priority.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Jan 2018 08:57:06 -0800

On Thu, Jan 18, 2018 at 3:21 AM, Alexandre Petrescu
<[email-masked]> wrote:
> like GNSS coordinates.  There _are_ Internet Draft proposals of putting GNSS
> coordinates in IPv6 extension headers.
>
Good point.

> Or my mind is too twisted by the geographical discussions in vehicular
No, it's not :-). Exposure of geo-location in IP addresses is a first
class concern for privacy so clarity is good here.

> 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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Jan 2018 09:06:43 -0800

> 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.
>
Mark, thanks for the great explanation! I completely agree that
"transform" is better terminology. We definitely want to distinguish
ILA from NAT, and an in fact I think your explanation is probably a
good basis for the "Why ILA is not NAT" section in the architecture
doc.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 18 Jan 2018 19:18:10 +0100

Le 18/01/2018 à 17:51, Tom Herbert a écrit :
> case

I agree.

> and try to keep the protocol generic for broadest applicability.

Something like "use-cases will be elaborated, including but not limited 
to datacenter, mobility".

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 18 Jan 2018 10:45:35 -0800

>> reversed, also doesn't matter.)

Mark, it was interesting the way you worded this. I think of ILA and “its domain” as the overlay and once the originated packet is transformed, it traverses the underlay.

Dino