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

[Behcet Sarikaya <[e-mail]>]

On Fri, Jun 1, 2018 at 9:50 AM, Saleem Bhatti <[e-mail]>
wrote:

> Behcet;
>
> On 01 Jun 2018, at 15:11, Behcet Sarikaya <[e-mail]> wrote:
>
> Saleem,
>
> On Fri, Jun 1, 2018 at 2:24 AM, Saleem Bhatti <[e-mail]>
> wrote:
>
>> Behcet;
>>
>> On 30 May 2018, at 22:48, Behcet Sarikaya <[e-mail]> wrote:
>>
>> 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.
>>
>>
>> Yes, it is already a feature - the behaviour is defined in RFC6741 -
>> please see above, my response to Tom's message.
>>
>>
>
>
> IPv6 is no go, then there is no need for
> ILNP, right?
>
>
> Sorry ... I do not understand.
>
>
I get IPv6 on my laptop, I did not do anything for that no installation no
configuration nothing needed.

So  if that is what you are happy with that is fine, let's stop arguing.

Behcet

> Cheers,
> --/Saleem
>
>
>
>
> Behcet
>
>> Cheers,
>> --/Saleem
>>
>>
>>
>>
>>
>>> 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/d
>>>> raft-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
>>>>
>>>>
>>>
>>>
>>
>>
>
>