Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

[Luigi Iannone <[e-mail]>]

> On 30 May 2018, at 20:36, Behcet Sarikaya <[e-mail]> wrote:
> 
> 
> 
> On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[e-mail] <mailto:[e-mail]>> wrote:
> Tom;
> 
> > On 30 May 2018, at 16:44, Tom Herbert <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > Behcet,
> > 
> > The statement "For ILNP the basic deployment requires end-systems to
> > be updated." is unscoped. As written, this would imply that all hosts
> > on the Internet need to be updated to support ILNP. That is simply a
> > non-starter.
> 
> Good catch - thanks.
> 
> > If the idea is that ILNP can be deployed by networks then
> > hosts within that network can be updated.
> 
> Only those end-systems that need to use ILNP need to be updated. ILNP nodes can work in networks with non-ILNP nodes - see Section 10.4 of RFC6741.
> 
> 
> > But, then the question
> > becomes how ILNP hosts are going to be able to talk non ILNP hosts
> > (say servers on the Internet). For that the an ILNP gateway or proxy
> > also must be deployed in the network.
> 
> A gateway or proxy is not required.
> 
> ILNPv6 can be seen as a superset of IPv6. ILNPv6 drops back to IPv6 when required - the process is described in Section 10.6 of RFC6741.
> 
> 
> So then it is no longer ILNP.

+1

Either you have both side speaking ILNPv6 or you are “stuck” with IPv6 pure and simple.

I was wondering:  assuming that you do not use DNS to contact a node, how do you know it supports ILNPv6?

Ciao

L.



> 
> Regards,
> Behcet 
> Cheers,
> --/Saleem
> 
> 
> > 
> > Tom
> > 
> > On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <[e-mail] <mailto:[e-mail]>> wrote:
> >> Luigi, Saleem,
> >> 
> >> What is the agreement now as to the revision of the draft?
> >> 
> >> I had already added some text regarding UE being alone on the link, i.e.
> >> point-to-point link in wireless networks, that should make both sides happy?
> >> 
> >> Regards,
> >> Behcet
> >> 
> >> On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[e-mail] <mailto:[e-mail]>> wrote:
> >>> 
> >>> Hi Saleem,
> >>> 
> >>> On 29 May 2018, at 12:03, Saleem Bhatti <[e-mail] <mailto:[e-mail]>> wrote:
> >>> 
> >>> Hello Luigi;
> >>> 
> >>> Thanks for your comments - my responses are inline, below.
> >>> 
> >>> On 29 May 2018, at 09:32, Luigi Iannone <[e-mail] <mailto:[e-mail]>> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> 
> >>> On 28 May 2018, at 19:16, Saleem Bhatti <[e-mail] <mailto:[e-mail]>> wrote:
> >>> 
> >>> There is some text which is incorrect - on page 4:
> >>> 
> >>> ----
> >>>   Furthermore, ILNP demands a change in the way local (e.g., within a
> >>>   LAN) communication is carried out, needing all of the devices to
> >>>   support ILNP.  This in turn may raise heavy deployability issues.
> >>> ----
> >>> 
> >>> This is not true - "all devices" do *not* need to be updated, but only
> >>> those end-systems that wish to use ILNPv6. Switches
> >>> 
> >>> 
> >>> Switches clearly do not need to be changed since they are L2.
> >>> 
> >>> 
> >>> Agreed.
> >>> 
> >>> However, the text clearly says "all of the devices", which is incorrect.
> >>> 
> >>> 
> >>> Agreed.
> >>> 
> >>> 
> >>> 
> >>> and routers
> >>> 
> >>> 
> >>> You need to implement the ILCC in your first hop router.
> >>> 
> >>> 
> >>> No, that is not required. I have a testbed at St Andrews and we run Linux
> >>> routers that are not modified, and are not ILNP-aware. For example, please
> >>> see the testbed experiment described in this paper:
> >>> 
> >>>  IP without IP addresses
> >>>  https://dl.acm.org/citation.cfm?doid=3012695.3012701 <https://dl.acm.org/citation.cfm?doid=3012695.3012701>
> >>> 
> >>> 
> >>> Thanks for the pointer. :-)
> >>> 
> >>> 
> >>> Then you need new ICMP messages, and few other tricks here and there in
> >>> existing stuff.
> >>> 
> >>> 
> >>> The new ICMP messages, e.g. Locator Updates for ILNPv6, RFC6743, are
> >>> end-to-end - only the end hosts needs to be updated to generate these
> >>> messages.
> >>> 
> >>> If any on-path routers wish to examine such messages, then yes, they would
> >>> need to be updated, but that is not required for ILNPv6 to work.
> >>> 
> >>> 
> >>> Ack.
> >>> 
> >>> 
> >>> Other solutions are more clear because introduce new entities and
> >>> protocol, so either you have it or you don’t.
> >>> 
> >>> 
> >>> Yet, may be the last sentence can be soften deleting  “heavy”.
> >>> 
> >>> 
> >>> All new solutions will incur some sort of deployment overhead, so I am not
> >>> sure why such a comment should apply specifically and only to ILNP.
> >>> 
> >>> For ILNP the basic deployment requires end-systems to be updated. Such
> >>> updates would be deployed through over-the-air updates, as is common today
> >>> with many operating systems. DNS entries for ILNP nodes would also be
> >>> needed, and the new DNS RRs for ILNP (RFC6742) are supported commercially
> >>> (e.g. by BIND, NSD, and KnotDNS, and possibly others)..
> >>> 
> >>> For other solutions, other deployment issues exist, e.g. for ILA and LISP,
> >>> new network entities/functions need to be deployed and managed for routing,
> >>> and so, I guess, the existing network will need to be reconfigured to
> >>> integrate the new functionality. I am guessing some operators may find that
> >>> a "heavy" deployment burden, but it is best that those operators comment on
> >>> whether or not they see that is a problem, as I have no experience with
> >>> running large networks.
> >>> 
> >>> 
> >>> Updating end-systems is IMHO a real nightmare. You have no control on who
> >>> will update and when. Network history is full of such examples.
> >>> Yes, ILA and LISP has to be deployed by operators, but they can have full
> >>> control of what will happen in their own network (which they usually like).
> >>> YMMV.
> >>> 
> >>> In general, I may agree that deployment considerations for all of the
> >>> considered solutions can be improved and corrected.
> >>> 
> >>> Thanks
> >>> 
> >>> L.
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> Cheers,
> >>> --/Saleem
> >>> 
> >>> 
> >>> Ciao
> >>> 
> >>> L.
> >>> 
> >>> 
> >>> do not need to be updated, as ILNPv6 is backwards compatible with IPv6. It
> >>> is possible to run an ILNPv6 node in a LAN which also has non-ILNPv6 nodes.
> >>> 
> >>> Cheers,
> >>> --/Saleem
> >>> 
> >>> 
> >>> On 25 May 2018, at 15:50, Behcet Sarikaya <[e-mail] <mailto:[e-mail]>> wrote:
> >>> 
> >>> Hi all,
> >>> 
> >>> We have submitted the gaps draft. Those who have contributed text are
> >>> listed as co-authors.
> >>> Please send your comments to the list.
> >>> 
> >>> Regards,
> >>> Dirk& Behcet
> >>> 
> >>> A new version of I-D, draft-xyzy-atick-gaps-00.txt
> >>> has been successfully submitted by Behcet Sarikaya and posted to the
> >>> IETF repository.
> >>> 
> >>> Name:           draft-xyzy-atick-gaps
> >>> Revision:       00
> >>> Title:          Gap and Solution Space Analysis for End to End Privacy
> >>> Enabled Mapping System
> >>> Document date:  2018-05-25
> >>> Group:          Individual Submission
> >>> Pages:          10
> >>> URL:
> >>> https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt <https://www.ietf.org/internet-drafts/draft-xyzy-atick-gaps-00.txt>
> >>> Status:         https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/ <https://datatracker.ietf.org/doc/draft-xyzy-atick-gaps/>
> >>> Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00 <https://tools.ietf.org/html/draft-xyzy-atick-gaps-00>
> >>> Htmlized:
> >>> https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps <https://datatracker.ietf.org/doc/html/draft-xyzy-atick-gaps>
> >>> 
> >>> 
> >>> Abstract:
> >>>   This document presents a gap and solution analysis for end-to-end
> >>>   privacy enabled mapping systems.  Each of the identifier locator
> >>>   separation system has its own approach to mapping identifiers to the
> >>>   locators.  We analyse all these approaches and identify the gaps in
> >>>   each of them and do a solution space analysis in an attempt to
> >>>   identify a mapping system that can be end to end privacy enabled.
> >>> 
> >>> 
> >>> 
> >>> 
> >>> Please note that it may take a couple of minutes from the time of
> >>> submission
> >>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >>> 
> >>> The IETF Secretariat
> >>> 
> >>> 
> >>> _______________________________________________
> >>> 5gangip mailing list
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >>> 
> >>> 
> >>> _______________________________________________
> >>> 5gangip mailing list
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> 5gangip mailing list
> >>> [e-mail] <mailto:[e-mail]>
> >>> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >>> 
> >> 
> >> 
> >> _______________________________________________
> >> 5gangip mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> >> 
> > 
> > _______________________________________________
> > 5gangip mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/5gangip <https://www.ietf.org/mailman/listinfo/5gangip>
> 
>