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

[Ravi Ravindran <[e-mail]>]

Dave,

Please see for my comments inline..

Regards,
Ravi

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

On 5 Jun 2017, at 12:32, Ravi Ravindran wrote:

> 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.

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.

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


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.

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.

> Regards,
> Ravi
>
>
>
> From: icnrg [mailto:[e-mail]] On Behalf Of David Oran
> Sent: Monday, June 05, 2017 7: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]



DaveO