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

[Dino Farinacci <[e-mail]>]

The reason I sent the note was because there was a comparison between ILA and ILNP. So I threw LISP in for completeness.

Dino

> On May 30, 2018, at 2:51 PM, Behcet Sarikaya <[e-mail]> wrote:
> 
> Hi Dino,
> 
> In this group we love all Id-Loc protocols, we strive for them to get better and hopefully one day that will pay off.
> 
> Behcet
> 
> On Wed, May 30, 2018 at 2:38 PM, Dino Farinacci <[e-mail]> wrote:
> And its irrelevant for LISP, because it can run in user-space.
> 
> Dino
> 
> > On 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 ;-)
> > 
> > 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
> >>> 
> >>> 
> >>> 
> > 
> > _______________________________________________
> > 5gangip mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/5gangip
> 
>