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

["David Oran" <[e-mail]>]

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]