Re: [icnrg] Comments on draft-rahman-icnrg-deployment-guidelines-01

["Rahman, Akbar" <[e-mail]>]

Hi Dave,


Thank you very much for your detailed comments.  The authors will review your comments, and we plan to have a new revision of the draft addressing your comments to be uploaded before the IETF-Prague submission deadline.  We look forward to presenting at the Prague main meeting, and continuing the discussion with you and the rest of the WG there.

Best Regards,

Akbar



[cid:imageae4d09.PNG@b0a17f84.47a90b88]
[cid:image9c55d6.PNG@9e61733f.4aa2d03d]<http://ir.interdigital.com/File/Index?KeyFile=37447876>


This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.


From: icnrg [mailto:[e-mail]] On Behalf Of David Oran
Sent: Monday, June 5, 2017 10:22 AM
To: [e-mail]
Subject: [icnrg] Comments on draft-rahman-icnrg-deployment-guidelines-01


I reviewed the current revision of Deployment Considerations for Information-Centric Networking (ICN). Here are my comments, with <Chair Hat Off>.

General Comments

I found this draft to be quite readable and to contain a lot of useful material. I think it is a good candidate for adoption as an ICNRG working draft, as the content is timely and does not significantly overlap our other ongoing work. It can act as a context in which other work can assess its benefits and problems when it reaches the maturity level for actual deployment on the Internet. Given the nature of much of the material, which documents what’s been tried in the past and what is being tried now, we could treat this as a living draft continually updated by ICNRG, or freeze it at some point for publication as an RFC. It’s probably premature to decide which path makes more sense.

As an individual I’d like to recommend that ICNRG adopt this as a work item; I found it mature enough to do this now but a lot more review by ICNRG participants is needed.

Detailed Comments
1 Introduction

  *   In the introduction, it would be better to say “Finally, recommendations are made for potential future IETF standardization” so we don’t go beyond the current level of understanding in the ICNRG.

2 Terminology

  *   The terminology section is kind of ok since the text concentrates on the few things needed to understand the rest of the draft, but it seems a bit strange to be defining ICN and SDN here. Maybe it would be better to say that to understand the draft you need to know what the terms “ICN” and “SDN” mean rather than offering your own definitions. At least for ICN, I’d recommend just referencing the terminology draft.

3.1 Wholesale Replacement

  *   I wouldn’t call out BF based forwarding elements as the first-order example of replacing IP routers with ICN routers. I’d first mention NFD as an NDN example, and CICN as a CCNx example, and possibly keep the BF reference just as a reference to other approaches.

3.3.2 Edge Network

  *   you mention translating incoming COAP transactions at an edge proxy, but not the reverse direction of translating ICN Interest/Data exchanges to COAP requests. Is this just an omission or is there some reason why it’s not a feasible deployment to allow requests to originate in the ICN edge. (I suspect you just mis-worded this).

3.4 ICN-in-a-slice

  *   I wouldn’t necessarily call SDN a “novel data plane”. Some SDN designs (e.g. Openflow) could be called novel because of the match-action paradigm which was pioneered by Openflow, but others use a conventional data plane and do SDN control/data plane splits with higher-level protocols like Yang/Netconf. I think this section needs some work. There are a bunch of interesting technical issues of how to take an ICN forwarding architecture and usefully map it into a control/data plane split. This document is probably not the place to do that. What I think you want to get across here is that the control of slices in current network slicing designs depends on some fairly rigid SDN assumptions, which may require ICN-specific features to be added to whatever SDN data plane is running in that slice.

4 Deployment Migration Paths

  *   I wonder if it wouldn’t be a good idea to include some material on IoT-edge providers given that IoT is an attractive target for ICN designs (or at least a lot of the ICN community hopes it is). This is more “greenfield” than “migration” but may wind up with a different sort of underlay (or overlay) than what would be used by conventional app developers, ISPs, etc.).

4.1 Application and Service Migration

  *   In the last paragraph, you say “This overlay and ICN-in-a-Slice approaches of deployment are likely to be more disruptive at the application and service level”. Disruptive in what sense? I’m not getting it.

4.2 Content Delivery Network Migration

  *   you missed one of the key reasons for deploying CDNs - reduction of origin server load.

4.4 Core Network Migration

  *   You seem to imply that by employing the native-ICN-in-a-slice technique, somehow the performance problems with ICN in a core network become easier. I doubt this is true. I suspect that even if you have a slice in order to isolate the traffic, some kind up tunneling underlay may be needed (e.g. MPLS). Basically, I think the slice capability is clearly a benefit for migration by isolating the traffic, but for core networks I’m not convinced it brings other benefits to ICN. The edge is another matter.

6 Deployment Issues Requiring further Standardization

  *   s/This section will address/This section addresses/

6.4 Summary of ICN Protocol Gaps and Potential IETF Efforts

·        First, Id say IETF or IRTF efforts, since right now the locus of work is in the IRTF and many of the questions raised in this document are naturally in the purview of the IRTF today.

·        Second, here is my one major problem with the draft. I think it is both premature and beyond the mandate of the ICNRG to be recommending to the IETF how it takes up technical work in the ICN arena. Therefore, I’d like to see table 1 redone to eliminate the “Potential IETF Group” material. I’d instead replace it with a column listing specific technical work needed to fill the gaps identified in the left column. Some of that material is already present in the form of parentheticals. This needs to be promoted to be the main point of the table, and hopefully augmented with more examples and possibly more specific descriptions on the needed design and implementation work.

[End of Comments]