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

Behcet;

On 30 May 2018, at 19:35, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> wrote:

On Wed, May 30, 2018 at 1:28 PM, David Allan I <david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>> wrote:
The only network upgrade for ILNP is DNS support for RFC 6742, which is believe is already deployed.

I am not sure about deployed but maybe defined is better.

If you are running the most recent version of BIND, KnotDNS, or NSD, then they support RFC6742 out-of-the-box, as far as I know.

Cheers,
--/Saleem

However, DNS is not privacy enabled which is our main issue here.

Regards,
Behcet
Cheers
Dave

-----Original Message-----
From: 5gangip <5gangip-bounces@ietf.org<mailto:5gangip-bounces@ietf.org>> On Behalf Of Saleem Bhatti
Sent: Wednesday, May 30, 2018 9:19 AM
To: Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>>
Cc: Luigi Iannone <ggx@gigix.net<mailto:ggx@gigix.net>>; 5GANGIP <5gangip@ietf.org<mailto:5gangip@ietf.org>>; Behcet Sarikaya <sarikaya@ieee.org<mailto:sarikaya@ieee.org>>
Subject: Re: [5gangip] New Version Notification for draft-xyzy-atick-gaps-00.txt

Tom;

> On 30 May 2018, at 16:44, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> 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.

Cheers,
--/Saleem

>
> Tom
>
> On Wed, May 30, 2018 at 7:20 AM, Behcet Sarikaya <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> 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 <ggx@gigix.net<mailto:ggx@gigix.net>> wrote:
>>>
>>> Hi Saleem,
>>>
>>> On 29 May 2018, at 12:03, Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>> wrote:
>>>
>>> Hello Luigi;
>>>
>>> Thanks for your comments - my responses are inline, below.
>>>
>>> On 29 May 2018, at 09:32, Luigi Iannone <ggx@gigix.net<mailto:ggx@gigix.net>> wrote:
>>>
>>> Hi,
>>>
>>>
>>> On 28 May 2018, at 19:16, Saleem Bhatti <saleem@st-andrews.ac.uk<mailto:saleem@st-andrews.ac.uk>> 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 <sarikaya2012@gmail.com<mailto:sarikaya2012@gmail.com>> 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
>>> 5gangip@ietf.org<mailto:5gangip@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> 5gangip@ietf.org<mailto:5gangip@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> 5gangip@ietf.org<mailto:5gangip@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>
>>
>>
>> _______________________________________________
>> 5gangip mailing list
>> 5gangip@ietf.org<mailto:5gangip@ietf.org>
>> https://www.ietf.org/mailman/listinfo/5gangip
>>
>
> _______________________________________________
> 5gangip mailing list
> 5gangip@ietf.org<mailto:5gangip@ietf.org>
> https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
5gangip@ietf.org<mailto:5gangip@ietf.org>
https://www.ietf.org/mailman/listinfo/5gangip