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

[Saleem Bhatti <[e-mail]>]

Behcet;

On 30 May 2018, at 15:20, Behcet Sarikaya <[e-mail]<mailto:[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?

The whole paragraph should be removed.

Cheers,
--/Saleem



Regards,
Behcet

On Tue, May 29, 2018 at 7:25 AM, Luigi Iannone <[e-mail]<mailto:[e-mail]>> wrote:
Hi Saleem,

On 29 May 2018, at 12:03, Saleem Bhatti <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:

Hi,


On 28 May 2018, at 19:16, Saleem Bhatti <[e-mail]<mailto:[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]<mailto:[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<http://tools.ietf.org/>.

The IETF Secretariat


_______________________________________________
5gangip mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/5gangip


_______________________________________________
5gangip mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/5gangip