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

[Tom Herbert <[e-mail]>]

On Wed, May 30, 2018 at 12:08 PM, Saleem Bhatti <[e-mail]> wrote:
>
>
>> 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 ;-)
>
Saleem,

I'm not sure how to interpret your response. ILA has been in upstream
for a while and is begin deployed. I know that ILNP is not in Linux,
but I don't know about other OSes.

Tom

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