Re: [Ila] [E] Re: Proposed charter

["Bogineni, Kalyani" <[e-mail]>]

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:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: Thursday, January 18, 2018 6:21 AM
> To: Tom Herbert <[e-mail]>
> Cc: [e-mail]
> Subject: [E] Re: [Ila] Proposed charter
> 
> 
> 
> 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://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=
> >
> 
> _______________________________________________
> ila mailing list
> [e-mail]
> 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
> =