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

[Saleem Bhatti <[e-mail]>]

Behcet;

On 30 May 2018, at 22:48, Behcet Sarikaya <[e-mail]<mailto:[e-mail]>> wrote:

Again trimming the cc list.


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

On 30 May 2018, at 19:36, Behcet Sarikaya <[e-mail]<mailto:[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.

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.

Cheers,
--/Saleem




Cheers,
--/Saleem



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
>>>
>>>
>>> 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
>>> 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<http://tools.ietf.org/>.
>>>
>>> The IETF Secretariat
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>
>>
>> _______________________________________________
>> 5gangip mailing list
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/5gangip
>>
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/5gangip