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

[Behcet Sarikaya <[e-mail]>]

Again trimming the cc list.


On Wed, May 30, 2018 at 1:52 PM, Saleem Bhatti <[e-mail]>
wrote:

> Behcet;
>
> On 30 May 2018, at 19:36, Behcet Sarikaya <[e-mail]> wrote:
>
>
>
> On Wed, May 30, 2018 at 11:19 AM, Saleem Bhatti <[e-mail]>
> wrote:
>
>> Tom;
>>
>> > On 30 May 2018, at 16:44, Tom Herbert <[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.
>
>
> To talk to an IPv6 host that does not talk ILNPv6, the easiest method is
> to talk IPv6.
>
>
Maybe a better reply is this feature could be added to ILNP.



> Cheers,
> --/Saleem
>
>
>
> Regards,
> Behcet
>
>> Cheers,
>> --/Saleem
>>
>>
>> >
>> > Tom
>> >
>> > On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <
>> [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]> wrote:
>> >>>
>> >>> Hi Saleem,
>> >>>
>> >>> On 29 May 2018, at 12:03, Saleem Bhatti <[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]> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>>
>> >>> On 28 May 2018, at 19:16, Saleem Bhatti <[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
>> >>>
>> >>>
>> >>> 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]>
>> 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
>> >>> Status:         https://datatracker.ietf.org/
>> doc/draft-xyzy-atick-gaps/
>> >>> Htmlized:       https://tools.ietf.org/html/draft-xyzy-atick-gaps-00
>> >>> Htmlized:
>> >>> 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.
>> >>>
>> >>> The IETF Secretariat
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 5gangip mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/5gangip
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 5gangip mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/5gangip
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> 5gangip mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/5gangip
>> >>>
>> >>
>> >>
>> >> _______________________________________________
>> >> 5gangip mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/5gangip
>> >>
>> >
>> > _______________________________________________
>> > 5gangip mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/5gangip
>>
>>
>
>