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

[Saleem Bhatti <[e-mail]>]

Luigi;

On 29 May 2018, at 13:25, 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,


 [ ... ]


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.

I agree deployment can be troublesome - deployment issues, in general, especially with heterogenous systems, can cause difficulty.

However, enterprise-wide solutions to such things exists today, and work successfully. For example, thinking about my own workplace (a university campus), hundreds (even thousands) of devices can be update in a coordinated manner using centrally-controlled management systems, for Windows and Linux. For individual users, yes, that is up to them, but for Linux/Mac/Windows/Android/IOS (at least) there are the various notifications to pester users to upgrade. :-)

ILNP would allow incremental upgrades for a site, as only those nodes that need to use ILNP need to be updated.

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.

Agreed.

However, that does not mean that the deployment will be easy, quick, or trouble-free, just that they (should) have administrative control. As I wrote previously, comments from an operator would be useful here, rather than an ungrounded opinion from me.

In general, I may agree that deployment considerations for all of the considered solutions can be improved and corrected.

Agreed.

Cheers,
--/Saleem



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