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

[Saleem Bhatti <[e-mail]>]

> On 30 May 2018, at 20:01, Tom Herbert <[e-mail]> wrote:
> 
> On Wed, May 30, 2018 at 11:48 AM, Saleem Bhatti <[e-mail]> wrote:
>> Behcet;
>> 
>> On 30 May 2018, at 19:35, Behcet Sarikaya <[e-mail]> wrote:
>> 
>> 
>> 
>> On Wed, May 30, 2018 at 1:28 PM, David Allan I <[e-mail]>
>> 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.
>> 
> The more relevant question would be which host OSes support ILNP.

Currently, probably about the same number as the networks that support ILA ;-)

Cheers,
--/Saleem


> 
> Tom
> 
>> Cheers,
>> --/Saleem
>> 
>> 
>> However, DNS is not privacy enabled which is our main issue here.
>> 
>> 
>> Regards,
>> Behcet
>>> 
>>> Cheers
>>> Dave
>>> 
>>> -----Original Message-----
>>> From: 5gangip <[e-mail]> On Behalf Of Saleem Bhatti
>>> Sent: Wednesday, May 30, 2018 9:19 AM
>>> To: Tom Herbert <[e-mail]>
>>> Cc: Luigi Iannone <[e-mail]>; 5GANGIP <[e-mail]>; Behcet
>>> Sarikaya <[e-mail]>
>>> Subject: Re: [5gangip] New Version Notification for
>>> draft-xyzy-atick-gaps-00.txt
>>> 
>>> 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.
>>> 
>>> 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
>>> 
>>> _______________________________________________
>>> 5gangip mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/5gangip
>> 
>> 
>>