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

[Behcet Sarikaya <[e-mail]>]

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?


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