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

[Behcet Sarikaya <[e-mail]>]

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