Re: [icnrg] Next steps on the 4G/LTE Draft

Akbar Rahman <Akbar.Rahman@InterDigital.com> Tue, 07 May 2019 20:12 UTC

Return-Path: <Akbar.Rahman@InterDigital.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A61120114 for <icnrg@ietfa.amsl.com>; Tue, 7 May 2019 13:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=interdigital.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yA1cK8kaY92 for <icnrg@ietfa.amsl.com>; Tue, 7 May 2019 13:12:33 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690095.outbound.protection.outlook.com [40.107.69.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD47120153 for <icnrg@irtf.org>; Tue, 7 May 2019 13:12:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=D6lwgV7a0uNhqzF5wi2lRoPgpVRMAXpvldApx7ufvn8=; b=x08q5SD+sHavpSlk9WKFZtucLPnEULBw0F9yhAogt8KdtAvMOj6yntouUAi/EhQFFqHQSY5WsbPYkkDDP6QY1cwwG8SW4Af/eRYFeCtKX2Hu3cs/BEFLl2kiTJAbnN39HwWz4z+jqecjXjA1lvE5DUW8gES9cvNsdw7YKVNzXAw=
Received: from DM6PR10MB3418.namprd10.prod.outlook.com (20.179.164.87) by DM6PR10MB2700.namprd10.prod.outlook.com (20.176.89.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Tue, 7 May 2019 20:12:29 +0000
Received: from DM6PR10MB3418.namprd10.prod.outlook.com ([fe80::3cb8:6938:a7bb:2b5f]) by DM6PR10MB3418.namprd10.prod.outlook.com ([fe80::3cb8:6938:a7bb:2b5f%5]) with mapi id 15.20.1856.012; Tue, 7 May 2019 20:12:29 +0000
From: Akbar Rahman <Akbar.Rahman@InterDigital.com>
To: "Jangam, Anil" <anjangam@cisco.com>, Luca Muscariello <luca.muscariello@gmail.com>
CC: icnrg <icnrg@irtf.org>, "Suthar, Prakash" <psuthar@cisco.com>, "Stolic, Milan" <mistolic@cisco.com>, Dirk Trossen <Dirk.Trossen@InterDigital.com>, Ravi Ravindran <ravi.ravindran@huawei.com>, "Oran, Dave" <daveoran@orandom.net>
Thread-Topic: [icnrg] Next steps on the 4G/LTE Draft
Thread-Index: AQHUdmbIZOMaPy78RUuviZ2U5SScsqVEBjKAgA0CZICBA3hAAIAMtDpg
Date: Tue, 07 May 2019 20:12:28 +0000
Message-ID: <DM6PR10MB3418FCADB4389AD70486A1A3E7310@DM6PR10MB3418.namprd10.prod.outlook.com>
References: <840FA4F4-2A4F-4DC7-AEE8-8EB3C11396B9@orandom.net> <CAHx=1M74vBMb8jtD+xA6bqCgOXY32cqgNisW95n9850igf5XEA@mail.gmail.com> <DM6PR10MB277769EDF2B31A9B4E483683F3DC0@DM6PR10MB2777.namprd10.prod.outlook.com> <3C1F27C1-15D3-4876-82E2-C6580C83ECC8@cisco.com>
In-Reply-To: <3C1F27C1-15D3-4876-82E2-C6580C83ECC8@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Akbar.Rahman@InterDigital.com;
x-originating-ip: [70.30.6.149]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1dc51bea-c42f-4757-e2d3-08d6d32854b4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM6PR10MB2700;
x-ms-traffictypediagnostic: DM6PR10MB2700:
x-ms-exchange-purlcount: 4
x-ld-processed: e351b779-f6d5-4e50-8568-80e922d180ae,ExtAddr
x-microsoft-antispam-prvs: <DM6PR10MB2700DA6F688B4C5107A52FFAE7310@DM6PR10MB2700.namprd10.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0030839EEE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39850400004)(396003)(366004)(376002)(51914003)(40134004)(199004)(189003)(7736002)(7696005)(76176011)(9686003)(110136005)(26005)(733005)(54906003)(55016002)(476003)(9326002)(229853002)(6436002)(25786009)(186003)(11346002)(99286004)(446003)(86362001)(81156014)(486006)(33656002)(5660300002)(81166006)(52536014)(8676002)(3846002)(790700001)(6116002)(6506007)(53546011)(102836004)(2906002)(8936002)(68736007)(606006)(256004)(4326008)(74316002)(66574012)(478600001)(66066001)(53936002)(54896002)(6306002)(236005)(316002)(72206003)(71190400001)(71200400001)(14444005)(66556008)(6246003)(73956011)(5024004)(76116006)(66476007)(66446008)(14454004)(66946007)(64756008)(966005)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR10MB2700; H:DM6PR10MB3418.namprd10.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: InterDigital.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: KbG/m7Inf7Y+aS1dsbSdxRp0Rkgb3MdL5+yjwU0XPg3OwY1LWdsmkzHvuGfxSfFrgmfIhIgCmJLj9elNJJxMWgNKjHNjKHIEu0ElIJRB2kCiNSga8G88rmVTcP7P5/1fhYMJrTfoZry8wi/3OwoIQKXQz/ZbYZVBMdb9HThRoVos9GDBWyZcfCfZTxNWaDcocWFwVv59W8+5GNtob2ATlWFSmtuBTJZSOp6BchAIj3DTVG/EWkl7fVfNaDJwSizUi2GBwFUWy23MGSSVOkQfwr0dRyu25Q+OiKcdnViUUny2nr51vSFO4mwb8JJFIU7w/GMVjIt6/ftTwe1izclZsg8G0tZDJ4MiXcOvU6LP42fUQYQcMAgy1BPkW+2oKf/pjIWk++frioegPRfU47XbpjFq9DpeW72UYO25RHAyOHM=
Content-Type: multipart/alternative; boundary="_000_DM6PR10MB3418FCADB4389AD70486A1A3E7310DM6PR10MB3418namp_"
MIME-Version: 1.0
X-OriginatorOrg: interdigital.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc51bea-c42f-4757-e2d3-08d6d32854b4
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2019 20:12:29.1186 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB2700
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/oK9Wsm7UbkUp5z2wn3S3x_dExJo>
Subject: Re: [icnrg] Next steps on the 4G/LTE Draft
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 20:12:37 -0000

Hi Anil,


Thanks for the updates.  I read it over and you have addressed all my comments (especially in section 4.7 and related text).  I think the draft is in good shape and I do support progressing it.


Best Regards,

Akbar

From: Anil Jangam (anjangam) <anjangam@cisco.com>
Sent: Monday, April 29, 2019 2:10 PM
To: Luca Muscariello <luca.muscariello@gmail.com>; Akbar Rahman <Akbar.Rahman@InterDigital.com>
Cc: icnrg <icnrg@irtf.org>; Suthar, Prakash <psuthar@cisco.com>; Stolic, Milan <mistolic@cisco.com>; Dirk Trossen <Dirk.Trossen@InterDigital.com>; Ravi Ravindran <ravi.ravindran@huawei.com>; Oran, Dave <daveoran@orandom.net>
Subject: Re: [icnrg] Next steps on the 4G/LTE Draft


Hello Luca, Rehman, and All,



We released an update to this draft (see attached) incorporating some of the feedback we received. Please let us know if this update meets your concerns.



We also call for your vote on moving this draft to RG last call. Please respond and let us know if you have any other feedback.



Thank you,

/anil.


icnrg on behalf of Trossen, Dirk icnrg-bounces@irtf.org<mailto:icnrg-bounces@irtf.org> on behalf of Dirk.Trossen@InterDigital.com<mailto:Dirk.Trossen@InterDigital.com> 11/15/18, 7:49 AM

Hi Luca,

The abstract provides a number of aspects for wanting to utilize ICN in 4G/LTE networks, such as “ICN has an inherent capability for multicast, anchorless mobility, security and it is optimized for data delivery using local caching at the edge.” – I agree that being brief, given that it’s in the abstract, but similar to what the paper discusses as opportunities. Furthermore, there’s a possible argument to be made that 4G/LTE will be around for some time to come, including being introduced in a number of markets as new deployments even – but should this be part of a technical draft?

I’m a bit confused by the ‘HAS to compare with those solutions’ comment. Do you expect a functional comparison, a reference to the (brief) discussion in Section V on possible deployments, …?

As for the HICN statement, I see your point on a possible misunderstanding (albeit it’s clear to me) – would you have a proposed improved formulation that avoids any such misunderstanding?

What is not clear to me though if your comment is meant as an opposition to the validity of the solution described in the draft and its adoption specifically?

Best,

Dirk

From: icnrg [mailto:icnrg-bounces@irtf.org] On Behalf Of Luca Muscariello
Sent: 07 November 2018 09:09
To: Oran, Dave <daveoran@orandom.net<mailto:daveoran@orandom.net>>
Cc: icnrg <icnrg@irtf.org<mailto:icnrg@irtf.org>>
Subject: Re: [icnrg] Next steps on the 4G/LTE Draft

Hi,

A few comments to the document:


The motivation of this document seems weak. E.g. Why should I do all these changes? Worth the pain?
Please find below a paper that may help to motivate that a little bit.

The following paper is also a good citation and the author of this draft should compare
at least with Sec V of it, where several deployment options where proposed including encapsulation in IP and GTP-U extension headers. This draft HAS to compare with those solutions. Beware that those solutions were Alcatel-Lucent IPR and should be Nokia IPR now.
There might be Orange SA IPR as well. If necessary I could check myself.

Until that comparison is not made, I feel this draft SHOULD NOT go through a final call.

G. Carofiglio, M. Gallo, L. Muscariello and D. Perino, "Scalable mobile backhauling via information-centric networking," The 21st IEEE International Workshop on Local and Metropolitan Area Networks, Beijing, 2015, pp. 1-6.


Minor:
This text is either wrong or inaccurate. Or maybe, it is so short that is prone to misguided interpretation.

       An alternative approach to implement ICN over IP is provided in

       Hybrid ICN [HICN], which implements ICN over IP by mapping of ICN

       names to the IPv4/IPv6 addresses.



HTH

Luca

On Wed, Nov 7, 2018 at 7:51 AM David R. Oran <daveoran@orandom.net<mailto:daveoran@orandom.net>> wrote:

At the ICNRG Interim meeting at IETF 103, we got an update status on https://datatracker.ietf..org/doc/draft-irtf-icnrg-icn-lte-4g/<https://datatracker.ietf.org/doc/draft-irtf-icnrg-icn-lte-4g/>

This document is reaching a mature state and the chairs would like to get a sense from the RG participants on two questions:
1.       Do you think this is ready for an RG last call, and if not, what additions/changes you would like to see to move it forward.
2.       Do you think the appropriate target for this particular set of work is the “Informational” or “Experimental RFC track. It seems to fall somewhat in a grey area between the two.

Please reply to the list. We would like to have feedback by the end of next week or so (November 17).

Dave, Dirk, & Börje.
_______________________________________________
icnrg mailing list
icnrg@irtf.org<mailto:icnrg@irtf.org>
https://www.irtf.org/mailman/listinfo/icnrg
[Banner]


[Banner] [Banner]
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.