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

From: "David Oran" <[email-masked]>
Date: Mon, 05 Jun 2017 10:22:13 -0400

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]

---

From: Ravi Ravindran <[email-masked]>
Date: Mon, 5 Jun 2017 16:32:02 +0000

A comment on slicing.

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.
Networking Slicing is about supporting multiple end-to-end service networks with diverse SLAs over a common pool of resources. More than SDN, NFV has bas a bigger play here. These logical network functions can be overlaid over an IP/MPLS network (physical resources can be strictly partitioned as well) or has state in the underlay the way ‘pure’ SDN would do. Also each slice can have centralized of distributed control plane, that is up to the slice requirement. With ICN, one can potentially have a dedicated air slice with ICN integrated in the eNodeB which is part of an ICN slice to support one or more services.
Regards,
Ravi

From: icnrg [mailto:[email-masked]] On Behalf Of David Oran
Sent: Monday, June 05, 2017 7:22 AM
To: [email-masked]
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]

---

From: "David Oran" <[email-masked]>
Date: Mon, 05 Jun 2017 12:43:17 -0400

> Networking Slicing is about supporting multiple end-to-end service networks with diverse SLAs over a common pool of resources. More than SDN, NFV has bas a bigger play here. These logical network f…

that may be true, but is orthogonal to my comment about slicing and data plane features.
If slicing only allows you to use different SLAs and control plane state on a common set of data plane forwarding capabilities, then this doesn’t help at all with the performance limitations that would arise trying to run an “native” ICN forwarding plane in a router/switch having only IP/MPLS./Ethernet wire speed performance. NFV doesn’t help here - it just diverts traffic to a different box/context which itself has performance limitations, so again I see slicing as bringing a convenient way to partition resources to the table, but not much else.

The meta-comment also stands - this document probably isn’t the place to discuss what ICN data plane features are needed when you do slicing. As you mention, it might be appropriate to call out NFV separately as a potential element of a deployment method, whether or not it gets combined with slicing.

DaveO.

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

DaveO

---

From: Ravi Ravindran <[email-masked]>
Date: Mon, 5 Jun 2017 17:10:52 +0000

Dave,

Please see for my comments inline..

Regards,
Ravi

-----Original Message-----
From: David Oran [mailto:[email-masked]] 
Sent: Monday, June 05, 2017 9:43 AM
To: Ravi Ravindran <[email-masked]>
Cc: [email-masked]
Subject: Re: [icnrg] Comments on draft-rahman-icnrg-deployment-guidelines-01

Ravi > I wasn’t referring to the forwarding performance requirements here that is part of the slice definition, and whether a slice's forwarding throughput, latency or other QoS requirements can be met depends on the resource pool over which network slicing would be conducted. My point was on clarifying what a slice meant, I would still refer to the NGMN's 5G white paper here: https://www.ngmn.org/uploads/media/NGMN_5G_White_Paper_V1_0.pdf

Ravi> Sure agree with this, NFV is only one of the ways, P4/POF could be another approach to realize ICN data plane. With NS, all we are saying is that this allows an opportunity to deploy ICN networks in 5G, how it should be done depends on NS framework capabilities, available resource pool etc.

DaveO.

DaveO

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 5 Jun 2017 19:59:06 +0000

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

<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:[email-masked]] On Behalf Of David Oran
Sent: Monday, June 5, 2017 10:22 AM
To: [email-masked]
Subject: [icnrg] Comments on draft-rahman-icnrg-deployment-guidelines-01

General Comments

Detailed Comments
1 Introduction

2 Terminology

3.3.2 Edge Network

3.4 ICN-in-a-slice

[End of Comments]

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 5 Jun 2017 20:08:10 +0000

Hi Ravi,

Thanks for your feedback and clarification on the ICN in a slice issue.  I will contact you off line to discuss what minimum text should be included in the Deployment Considerations draft.  We should probably just cover the main points suggested by Dave in our Deployment Considerations draft.

/Akbar

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Ravi Ravindran
Sent: Monday, June 5, 2017 1:11 PM
To: David Oran <[email-masked]>
Cc: [email-masked]
Subject: Re: [icnrg] Comments on draft-rahman-icnrg-deployment-guidelines-01

Dave,

Regards,
Ravi

-----Original Message-----
From: David Oran [mailto:[email-masked]]
Sent: Monday, June 05, 2017 9:43 AM
To: Ravi Ravindran <[email-masked]>
Cc: [email-masked]
Subject: Re: [icnrg] Comments on draft-rahman-icnrg-deployment-guidelines-01

DaveO.

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

DaveO
_______________________________________________
icnrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/icnrg