Subject: Re: [icnrg] Review and update of draft-rahman-icnrg-deployment-guidelines

From: "Giovanna Carofiglio (gcarofig)" <[email-masked]>
Date: Thu, 23 Nov 2017 16:05:36 +0000

Dear Akbar and co-authors of "draft-rahman-icnrg-deployment guidelines",

I have reviewed the paragraphs describing Hybrid ICN and found them not representative of the solution we at Cisco have developed. Here the main points that should be revised: 

- Hybrid ICN does NOT deploy ICN as an overlay, it is rather what by design have decided not to do, btw for the reasons mentioned at the end of that section. Hybrid ICN aims at integrating ICN inside IP, using RFC standard IP packets and guaranteeing transparent interconnection of Hybrid ICN and IP routers (as described in the white paper in the references).

- As a consequence of my previous note, Hybrid ICN does NOT result in islands of ICN deployments over existing IP-based infrastructure. No tunnels are established and IP routers are transparently traversed with normal IP forwarding performed.

-  Hybrid ICN does NOT require  interoperability between existing IP routing protocols (e.g.  OSPF, RIP, ISIS) and ICN based ones, as incorrectly stated in the document. 

- Also, Hybrid ICN does not use the CCN protocol (CICN and Hybrid ICN are two different solutions).

We hope to be able to attend next ICNRG meetings where to contribute more details on Hybrid ICN. In the meantime, please feel free to reach out to me, or to Luca Muscariello ([email-masked]) to revise Hybrid ICN description. 

Thanks in advance. 

Best Regards,
Giovanna

________________________________________
From: icnrg <[email-masked]> on behalf of Rahman, Akbar <[email-masked]>
Sent: Friday, October 27, 2017 7:53 PM
To: Prakash Suthar (psuthar); icnrg
Cc: Börje Ohlman; Oran, Dave
Subject: [icnrg] Review and update of draft-rahman-icnrg-deployment-guidelines

Hi Prakash & Chairs,

We have updated our draft to address the comments from Prakish and some of his other colleagues at Cisco (who gave us some more off-line comments):

https://tools.ietf.org/html/draft-rahman-icnrg-deployment-guidelines-04

Here is the specific list of changes we made:

1.      Clarified that ICN can be run on many types of networks (access, transport, edge processing, CDN, core, data center, etc.) though in the main discussion text we just stuck to access network, core network and CDNs for simplicity

2.      Changed “wholesale replacement” to the more commonly used “clean-slate”, and clarified that it involves changes to existing applications, protocol stacks, etc. in addition to changes to IP routing

3.      Clarified interaction between normal IP routing running in the Internet and ICN based routing in (1) ICN-as-an-Overlay, and (2) ICN-as-an-Underlay

4.      Added references to ONAP.org which does MANO support for ICN-as-a-Slice

5.      Added more details about Cisco’s Hybrid-ICN approach, including reference to their open source Cicn project, and expected trials

6.      Clarified the main stakeholders in ICN deployments (included adding end device manufacturer and user)

7.      Clarified details of NDN testbed

We look forward to presenting and discussing more in Singapore.

Best Regards,

Akbar

-----Original Message-----
From: Rahman, Akbar
Sent: Sunday, October 1, 2017 8:19 PM
To: Suthar, Prakash <[email-masked]>; icnrg <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; Oran, Dave <[email-masked]>; [email-masked]
Subject: RE: [icnrg] New Version Notification for draft-rahman-icnrg-deployment-guidelines-03.txt

Hi Prakash,

Thank you very much for your detailed comments.  I will review them with the rest of the authors and also take up your kind offer to discuss with you off line.  We will plan to update our draft before Singapore to address your comments.

Best Regards,

Akbar

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Suthar, Prakash
Sent: Saturday, September 30, 2017 9:52 PM
To: Rahman, Akbar <[email-masked]>; icnrg <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; Oran, Dave <[email-masked]>; [email-masked]
Subject: Re: [icnrg] New Version Notification for draft-rahman-icnrg-deployment-guidelines-03.txt

Hi Akbar,
Greeting.
I have reviewed https://tools.ietf.org/html/draft-rahman-icnrg-deployment-guidelines-03 and I have following comments for enhancement of document.

Section 3.1 –
Paragraph specifies that ICN deployment might be clean-slate replacing large part of network, however considering practical network limitations we should propose ICN deployments as different options.
1.      Clean slate or Native ICN
2.      Dual stack (IPoICN, ICNoIP)
3.      Hybrid (ICN packets encoded inside existing IP ) e.g. hICN proposed by Cisco
4.      Any future technologies..

Can we also refer to dis-aggregations of hardware and software using white boxes that provides a mechanism to tightly integrate ICN protocol inside routing platforms? You can refer to http://www.fiercetelecom.com/telecom/at-t-s-white-box-trial-signals-disaggregated-platform-movement-driving-service-agility

Section 3.4
ICN provides a mechanism to be offered as slice i.e. “ICN-as-a-Slice” in existing IP infrastructure. “ICN-as-a-Slice” can be created using “cross-domain orchestrator”. Cross-domain orchestrator shall be capable of creating resources at service edge, transport (edge and core), applications platforms by automating whole life cycle.  You can also provide reference to Linux foundation OANP for cross-domain orchestrator.

For Hybrid ICN kindly refer to https://www.cisco.com/c/dam/en/us/solutions/collateral/service-provider/ultra-services-platform/mwc17-hicn-video-wp.pdf). Hybrid ICN (aka hICN) provides mechanism to carry ICN packet information as a payload inside IP datagram.

Section 3.3.2 Edge Network Migration
Para-1: One of my suggestions is to rename “Edge Network” to “Service Edge”. Most of services will be hosted at the edge in MEC, and you can suggest to use any of ICN deployment scenarios (refer sec 3.1).

Para-2: For mobile networks, ICN protocol stack can be integrated in eNodeB. You can refer to our draft draft-suthar-icnrg-icn-lte-4g-03. Section 4.5 provides different mechanisms “ICN deployment in eNodeB”.

Section 4 - Deployment Migration Paths
We should put 4th stake holder as UE or end user because they should be able to indicate how they want to consume content by indicating preference such as IP, ICN or don’t care. In draft-suthar-icnrg-icn-lte-4g-03 section 4.4.1 we have provided options by introducing “transport convergence layer” which can be used to indicate user’s choice.

Section 5.1
Do you want to mention hICN work done by Cisco where we are able to show performance efficiencies using hICN over IP based network? We have released community ICN at fd.io https://wiki.fd.io/view/Cicn

Any deployment or testbed reference to scalable Name resolution and NSLR will be helpful. My colleague Anil has done testing at scale for NSLR and you can cite reference.

Section 7
Para-1: Update with hICN.

On 9/7/17, 12:03 PM, "David Oran" <[email-masked]> wrote:

   I checked the minutes and it isn’t clear who the second volunteer was.
   Hannu, did you volunteer to review the -03 version?

   On 14 Aug 2017, at 15:03, Rahman, Akbar wrote:

   > Hi Chairs,
   >
   > https://tools.ietf.org/html/draft-rahman-icnrg-deployment-guidelines-03
   >
   > We decided to do a quick update of our draft to address the meeting
   > comments from Prague.
   >
   > Prakahsh and Haru (?) - Please use this version for your review
   > comments.
   >
   >
   > Below is a short summary of the updates:
   > -------------------------------------------------------
   > 1.      Added reference to dual mode devices in section 4.1
   > (Application and Service Migration) and referenced Prakash’s
   > “Native ICN for LTE” as an example.
   > 2.      Added a summary section of deployment trial experiences in new
   > section 5.3 to draw conclusions from our analysis of the various
   > deployments.
   >        •       This addresses Eve Schooler’s question of
   > “whether ICN technology is ready for prime time deployment?”
   > 3.      Scrubbed section 6 “further standardization” and added
   > some more items (i.e. OAM, SFC impacts) to summary of protocol gaps
   > Table 1 and corresponding text.
   > 4.      Added references to ICN over Low Power WLAN experiments from
   > Thomas Schmidt, and added new section 5.2.4. (NDN IoT Trials)
   > 5.      Various editorial updates including:
   >        •       Adding reference to ICNRG Charter in Intro
   >        •       Clarified the differences in the island approach
   > between “ICN-as-an-Overlay” and “ICN-as-an-Underlay” (i.e.
   > former connected by ICN/IP tunnels, and later going through gateways)
   > 6.      Note: We think points 1 and 4 above together address Lixia’s
   > comment on explicitly addressing “native ICN directly on top of
   > wireless”.
   >
   > -------------------------------------------------------
   >
   >
   > 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.
   >
   >
   > -----Original Message-----
   > From: [email-masked] [mailto:[email-masked]]
   > Sent: Monday, August 14, 2017 2:51 PM
   > To: Ravi Ravindran <[email-masked]>; Trossen, Dirk
   > <[email-masked]>; Dirk Kutscher <[email-masked]>;
   > Ravi Ravindrna <[email-masked]>; Rahman, Akbar
   > <[email-masked]>; Trossen, Dirk
   > <[email-masked]>
   > Subject: New Version Notification for
   > draft-rahman-icnrg-deployment-guidelines-03.txt
   >
   >
   > A new version of I-D, draft-rahman-icnrg-deployment-guidelines-03.txt
   > has been successfully submitted by Akbar Rahman and posted to the IETF
   > repository.
   >
   > Name:           draft-rahman-icnrg-deployment-guidelines
   > Revision:       03
   > Title:          Deployment Considerations for Information-Centric
   > Networking (ICN)
   > Document date:  2017-08-14
   > Group:          Individual Submission
   > Pages:          23
   > URL:
   > https://www.ietf.org/internet-drafts/draft-rahman-icnrg-deployment-guidelines-03.txt
   > Status:
   > https://datatracker.ietf.org/doc/draft-rahman-icnrg-deployment-guidelines/
   > Htmlized:
   > https://tools.ietf.org/html/draft-rahman-icnrg-deployment-guidelines-03
   > Htmlized:
   > https://datatracker.ietf.org/doc/html/draft-rahman-icnrg-deployment-guidelines-03
   > Diff:
   > https://www.ietf.org/rfcdiff?url2=draft-rahman-icnrg-deployment-guidelines-03
   >
   > Abstract:
   >   Information-Centric Networking (ICN) is now reaching technological
   >   maturity after many years of fundamental research and
   >   experimentation.  This document provides a number of deployment
   >   considerations in the interest of helping the ICN community move
   >   forward to the next step of live deployments.  First, the major
   >   deployment configurations for ICN are described including the main
   >   overlay and underlay approaches.  Then proposed deployment migration
   >   paths are outlined to address major practical issues such as network
   >   and application migration.  Next, selected ICN trial experiences are
   >   summarized.  Finally, protocol areas that require further
   >   standardization are identified to facilitate future interoperable
   > ICN
   >   deployments.
   >
   >
   >
   >
   > 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.
   >
   > The IETF Secretariat
   >
   > _______________________________________________
   > icnrg mailing list
   > [email-masked]
   > https://www.irtf.org/mailman/listinfo/icnrg

   DaveO

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

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Thu, 23 Nov 2017 20:47:52 +0000

Dear Giovanna,

Thank you for your valuable input.  We had been working closely with your colleague, Prakash, for the last update but obviously perhaps the text related to Hybrid ICN needs further clarification.  I will work on clarifying according to your comments.

I also recently received separate off line comments from Hitoshi Asaeda on CUTEi and ICN2020 which I also need to address.

I will wait for the Chairs guidance on whether we should do this update before or after the WG adoption goes out on the mailing list as we discussed in Singapore.

Akbar

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Giovanna Carofiglio (gcarofig)
Sent: Thursday, November 23, 2017 11:06 AM
To: Rahman, Akbar <[email-masked]>; Suthar, Prakash <[email-masked]>; icnrg <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; Oran, Dave <[email-masked]>
Subject: Re: [icnrg] Review and update of draft-rahman-icnrg-deployment-guidelines

Thanks in advance.

Best Regards,
Giovanna

Hi Prakash & Chairs,

2.      Changed "wholesale replacement" to the more commonly used "clean-slate", and clarified that it involves changes to existing applications, protocol stacks, etc. in addition to changes to IP routing

5.      Added more details about Cisco's Hybrid-ICN approach, including reference to their open source Cicn project, and expected trials

Best Regards,

Akbar

-----Original Message-----
From: Rahman, Akbar
Sent: Sunday, October 1, 2017 8:19 PM
To: Suthar, Prakash <[email-masked]>; icnrg <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; Oran, Dave <[email-masked]>; [email-masked]
Subject: RE: [icnrg] New Version Notification for draft-rahman-icnrg-deployment-guidelines-03.txt

Hi Prakash,

Best Regards,

Akbar

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Suthar, Prakash
Sent: Saturday, September 30, 2017 9:52 PM
To: Rahman, Akbar <[email-masked]>; icnrg <[email-masked]>
Cc: Börje Ohlman <[email-masked]>; Oran, Dave <[email-masked]>; [email-masked]
Subject: Re: [icnrg] New Version Notification for draft-rahman-icnrg-deployment-guidelines-03.txt

Hi Akbar,
Greeting.

Section 3.1 -

Section 3.4
ICN provides a mechanism to be offered as slice i.e. "ICN-as-a-Slice" in existing IP infrastructure. "ICN-as-a-Slice" can be created using "cross-domain orchestrator". Cross-domain orchestrator shall be capable of creating resources at service edge, transport (edge and core), applications platforms by automating whole life cycle.  You can also provide reference to Linux foundation OANP for cross-domain orchestrator.

Section 3.3.2 Edge Network Migration
Para-1: One of my suggestions is to rename "Edge Network" to "Service Edge". Most of services will be hosted at the edge in MEC, and you can suggest to use any of ICN deployment scenarios (refer sec 3.1).

Para-2: For mobile networks, ICN protocol stack can be integrated in eNodeB. You can refer to our draft draft-suthar-icnrg-icn-lte-4g-03. Section 4.5 provides different mechanisms "ICN deployment in eNodeB".

Section 4 - Deployment Migration Paths
We should put 4th stake holder as UE or end user because they should be able to indicate how they want to consume content by indicating preference such as IP, ICN or don't care. In draft-suthar-icnrg-icn-lte-4g-03 section 4.4.1 we have provided options by introducing "transport convergence layer" which can be used to indicate user's choice.

Section 5.1

Section 7

   I checked the minutes and it isn't clear who the second volunteer was.
   Hannu, did you volunteer to review the -03 version?

   On 14 Aug 2017, at 15:03, Rahman, Akbar wrote:

   > (Application and Service Migration) and referenced Prakash's
   > "Native ICN for LTE" as an example.
   >        *       This addresses Eve Schooler's question of
   > "whether ICN technology is ready for prime time deployment?"
   > 3.      Scrubbed section 6 "further standardization" and added
   >        *       Adding reference to ICNRG Charter in Intro
   >        *       Clarified the differences in the island approach
   > between "ICN-as-an-Overlay" and "ICN-as-an-Underlay" (i.e.
   > 6.      Note: We think points 1 and 4 above together address Lixia's
   > comment on explicitly addressing "native ICN directly on top of
   > wireless".
   >

   DaveO

_______________________________________________
icnrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/icnrg
[Banner]<http://www.interdigital.com>
[Banner]<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: Luca Muscariello <[email-masked]>
Date: Thu, 23 Nov 2017 21:57:16 +0100

The little that is public on hICN is at least available from the
proceedings of the
31st ICNRG meeting (Interim) Chicago, USA March 2017

https://datatracker.ietf.org/meeting/interim-2017-icnrg-01/m
aterials/slides-interim-2017-icnrg-01-sessa-community-inform
ation-centric-networking-open-source-project-luca-muscariello/

slide #16,#17.

It does not make much sense to me to add text about hICN as long as
documentation is not ready yet.

Best
Luca

On Thu, Nov 23, 2017 at 9:47 PM, Rahman, Akbar <
[email-masked]> wrote:

> Dear Giovanna,
>
>
> Thank you for your valuable input.  We had been working closely with your
> colleague, Prakash, for the last update but obviously perhaps the text
> related to Hybrid ICN needs further clarification.  I will work on
> clarifying according to your comments.
>
> I also recently received separate off line comments from Hitoshi Asaeda on
> CUTEi and ICN2020 which I also need to address.
>
> I will wait for the Chairs guidance on whether we should do this update
> before or after the WG adoption goes out on the mailing list as we
> discussed in Singapore.
>
>
> Akbar
>
> To: Rahman, Akbar <[email-masked]>; Suthar, Prakash <
> [email-masked]>; icnrg <[email-masked]>
> I have reviewed the paragraphs describing Hybrid ICN and found them not
> representative of the solution we at Cisco have developed. Here the main
> points that should be revised:
>
> - Hybrid ICN does NOT deploy ICN as an overlay, it is rather what by
> design have decided not to do, btw for the reasons mentioned at the end of
> that section. Hybrid ICN aims at integrating ICN inside IP, using RFC
> standard IP packets and guaranteeing transparent interconnection of Hybrid
> ICN and IP routers (as described in the white paper in the references).
>
> - As a consequence of my previous note, Hybrid ICN does NOT result in
> islands of ICN deployments over existing IP-based infrastructure. No
> tunnels are established and IP routers are transparently traversed with
> normal IP forwarding performed.
>
> -  Hybrid ICN does NOT require  interoperability between existing IP
> routing protocols (e.g.  OSPF, RIP, ISIS) and ICN based ones, as
> incorrectly stated in the document.
>
> We hope to be able to attend next ICNRG meetings where to contribute more
> details on Hybrid ICN. In the meantime, please feel free to reach out to
> me, or to Luca Muscariello ([email-masked]) to revise Hybrid ICN
> description.
>
> Thanks in advance.
>
> Best Regards,
> Giovanna
>
>
>
> We have updated our draft to address the comments from Prakish and some of
> his other colleagues at Cisco (who gave us some more off-line comments):
>
> 1.      Clarified that ICN can be run on many types of networks (access,
> transport, edge processing, CDN, core, data center, etc.) though in the
> main discussion text we just stuck to access network, core network and CDNs
> for simplicity
>
> 2.      Changed "wholesale replacement" to the more commonly used
> "clean-slate", and clarified that it involves changes to existing
> applications, protocol stacks, etc. in addition to changes to IP routing
>
> 3.      Clarified interaction between normal IP routing running in the
> Internet and ICN based routing in (1) ICN-as-an-Overlay, and (2)
> ICN-as-an-Underlay
>
> 5.      Added more details about Cisco's Hybrid-ICN approach, including
> reference to their open source Cicn project, and expected trials
>
> Cc: Börje Ohlman <[email-masked]>; Oran, Dave <
> [email-masked]>; [email-masked]
> Subject: RE: [icnrg] New Version Notification for
> Thank you very much for your detailed comments.  I will review them with
> the rest of the authors and also take up your kind offer to discuss with
> you off line.  We will plan to update our draft before Singapore to address
> your comments.
>
>
> Best Regards,
>
>
> Akbar
>
> Cc: Börje Ohlman <[email-masked]>; Oran, Dave <
> [email-masked]>; [email-masked]
> Subject: Re: [icnrg] New Version Notification for
> I have reviewed https://tools.ietf.org/html/draft-rahman-icnrg-deployment-
> guidelines-03 and I have following comments for enhancement of document.
>
> Section 3.1 -
> Paragraph specifies that ICN deployment might be clean-slate replacing
> large part of network, however considering practical network limitations we
> should propose ICN deployments as different options.
> Can we also refer to dis-aggregations of hardware and software using white
> boxes that provides a mechanism to tightly integrate ICN protocol inside
> routing platforms? You can refer to http://www.fiercetelecom.com/
> telecom/at-t-s-white-box-trial-signals-disaggregated-
> platform-movement-driving-service-agility
>
> Section 3.4
> ICN provides a mechanism to be offered as slice i.e. "ICN-as-a-Slice" in
> existing IP infrastructure. "ICN-as-a-Slice" can be created using
> "cross-domain orchestrator". Cross-domain orchestrator shall be capable of
> creating resources at service edge, transport (edge and core), applications
> platforms by automating whole life cycle.  You can also provide reference
> to Linux foundation OANP for cross-domain orchestrator.
>
> For Hybrid ICN kindly refer to https://www.cisco.com/c/dam/
> en/us/solutions/collateral/service-provider/ultra-
> services-platform/mwc17-hicn-video-wp.pdf). Hybrid ICN (aka hICN)
> provides mechanism to carry ICN packet information as a payload inside IP
> datagram.
>
> Para-1: One of my suggestions is to rename "Edge Network" to "Service
> Edge". Most of services will be hosted at the edge in MEC, and you can
> suggest to use any of ICN deployment scenarios (refer sec 3.1).
>
> Para-2: For mobile networks, ICN protocol stack can be integrated in
> eNodeB. You can refer to our draft draft-suthar-icnrg-icn-lte-4g-03.
> Section 4.5 provides different mechanisms "ICN deployment in eNodeB".
>
> We should put 4th stake holder as UE or end user because they should be
> able to indicate how they want to consume content by indicating preference
> such as IP, ICN or don't care. In draft-suthar-icnrg-icn-lte-4g-03
> section 4.4.1 we have provided options by introducing "transport
> convergence layer" which can be used to indicate user's choice.
>
>
> Section 5.1
> Do you want to mention hICN work done by Cisco where we are able to show
> performance efficiencies using hICN over IP based network? We have released
> community ICN at fd.io https://wiki.fd.io/view/Cicn
>
> Any deployment or testbed reference to scalable Name resolution and NSLR
> will be helpful. My colleague Anil has done testing at scale for NSLR and
> you can cite reference.
>
> Section 7
>    > <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: "David Oran" <[email-masked]>
Date: Sat, 25 Nov 2017 16:41:36 +0700

On 24 Nov 2017, at 3:47, Rahman, Akbar wrote:

> Dear Giovanna,
>
>
> Thank you for your valuable input.  We had been working closely with 
> your colleague, Prakash, for the last update but obviously perhaps the 
> text related to Hybrid ICN needs further clarification.  I will work 
> on clarifying according to your comments.
>
> I also recently received separate off line comments from Hitoshi 
> Asaeda on CUTEi and ICN2020 which I also need to address.
>
> I will wait for the Chairs guidance on whether we should do this 
> update before or after the WG adoption goes out on the mailing list as 
> we discussed in Singapore.
>
don’t wait to work on the draft.

> To: Rahman, Akbar <[email-masked]>; Suthar, Prakash 
> <[email-masked]>; icnrg <[email-masked]>
> I have reviewed the paragraphs describing Hybrid ICN and found them 
> not representative of the solution we at Cisco have developed. Here 
> the main points that should be revised:
>
> design have decided not to do, btw for the reasons mentioned at the 
> end of that section. Hybrid ICN aims at integrating ICN inside IP, 
> using RFC standard IP packets and guaranteeing transparent 
> interconnection of Hybrid ICN and IP routers (as described in the 
> white paper in the references).
>
> tunnels are established and IP routers are transparently traversed 
> with normal IP forwarding performed.
>
> We hope to be able to attend next ICNRG meetings where to contribute 
> more details on Hybrid ICN. In the meantime, please feel free to reach 
> out to me, or to Luca Muscariello ([email-masked]) to revise 
> Hybrid ICN description.
>
> Thanks in advance.
>
> Best Regards,
> Giovanna
>
>
>
> We have updated our draft to address the comments from Prakish and 
> some of his other colleagues at Cisco (who gave us some more off-line 
> comments):
>
> 1.      Clarified that ICN can be run on many types of networks 
> (access, transport, edge processing, CDN, core, data center, etc.) 
> though in the main discussion text we just stuck to access network, 
> core network and CDNs for simplicity
>
> 5.      Added more details about Cisco's Hybrid-ICN approach, 
> including reference to their open source Cicn project, and expected 
> trials
>
> Cc: Börje Ohlman <[email-masked]>; Oran, Dave 
> <[email-masked]>; [email-masked]
> Thank you very much for your detailed comments.  I will review them 
> with the rest of the authors and also take up your kind offer to 
> discuss with you off line.  We will plan to update our draft before 
> Singapore to address your comments.
>
>
> Best Regards,
>
>
> Akbar
>
> Cc: Börje Ohlman <[email-masked]>; Oran, Dave 
> <[email-masked]>; [email-masked]
> I have reviewed 
> and I have following comments for enhancement of document.
>
> Section 3.1 -
> large part of network, however considering practical network 
> limitations we should propose ICN deployments as different options.
> Can we also refer to dis-aggregations of hardware and software using 
> white boxes that provides a mechanism to tightly integrate ICN 
> protocol inside routing platforms? You can refer to 
> http://www.fiercetelecom.com/telecom/at-t-s-white-box-trial-signals-disaggregated-platform-movement-driving-service-agility
>
> Section 3.4
> ICN provides a mechanism to be offered as slice i.e. "ICN-as-a-Slice" 
> in existing IP infrastructure. "ICN-as-a-Slice" can be created using 
> "cross-domain orchestrator". Cross-domain orchestrator shall be 
> capable of creating resources at service edge, transport (edge and 
> core), applications platforms by automating whole life cycle.  You can 
> also provide reference to Linux foundation OANP for cross-domain 
> orchestrator.
>
> For Hybrid ICN kindly refer to 
> https://www.cisco.com/c/dam/en/us/solutions/collateral/service-provider/ultra-services-platform/mwc17-hicn-video-wp.pdf). 
> Hybrid ICN (aka hICN) provides mechanism to carry ICN packet 
> information as a payload inside IP datagram.
>
> We should put 4th stake holder as UE or end user because they should 
> be able to indicate how they want to consume content by indicating 
> preference such as IP, ICN or don't care. In 
> draft-suthar-icnrg-icn-lte-4g-03 section 4.4.1 we have provided 
> options by introducing "transport convergence layer" which can be used 
> to indicate user's choice.
>
>
> Section 5.1
> Do you want to mention hICN work done by Cisco where we are able to 
> show performance efficiencies using hICN over IP based network? We 
> have released community ICN at fd.io https://wiki.fd.io/view/Cicn
>
> Any deployment or testbed reference to scalable Name resolution and 
> NSLR will be helpful. My colleague Anil has done testing at scale for 
> NSLR and you can cite reference.
>
> Section 7
>    > A new version of I-D, 

DaveO