Re: [icnrg] New Version Notification for draft-ravi-ccn-forwarding-label-01.txt

<Marc.Mosko@parc.com> Thu, 05 November 2015 00:41 UTC

Return-Path: <Marc.Mosko@parc.com>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B151B33AC for <icnrg@ietfa.amsl.com>; Wed, 4 Nov 2015 16:41:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 D-vFAg-RpKdj for <icnrg@ietfa.amsl.com>; Wed, 4 Nov 2015 16:41:11 -0800 (PST)
Received: from omega.xerox.com (omega.xerox.com [13.1.64.95]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7159D1B34FB for <icnrg@irtf.org>; Wed, 4 Nov 2015 16:40:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by omega.xerox.com (Postfix) with ESMTP id DFFBA5201D1; Wed, 4 Nov 2015 16:40:36 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at parc.com
Received: from omega.xerox.com ([127.0.0.1]) by localhost (smtp.parc.xerox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAdErXzXDkX5; Wed, 4 Nov 2015 16:40:36 -0800 (PST)
Received: from exchangehub.parc.xerox.com (vertigo.parc.xerox.com [13.2.13.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by omega.xerox.com (Postfix) with ESMTPS id C13D25201C3; Wed, 4 Nov 2015 16:40:36 -0800 (PST)
Received: from E2010DAG5.corp.ad.parc.com ([fe80::3d0b:7158:aec4:e05e]) by vertigo.corp.ad.parc.com ([fe80::606e:47ce:f5e2:fe3a%16]) with mapi id 14.03.0224.002; Wed, 4 Nov 2015 16:40:36 -0800
From: Marc.Mosko@parc.com
To: ravi.ravindran@huawei.com, icnrg@irtf.org
Thread-Topic: New Version Notification for draft-ravi-ccn-forwarding-label-01.txt
Thread-Index: AQHRFrRN4+q1KH1BE0ux0K5LeKCmpJ6LQn4AgAFU15w=
Date: Thu, 05 Nov 2015 00:40:35 +0000
Message-ID: <7CB233D07722374DB3A5C088E1E8088B7293427F@e2010dag5.corp.ad.parc.com>
References: <D96E28F4A22C864DBC6C871B5B1C4CC320B5A062@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <D96E28F4A22C864DBC6C871B5B1C4CC320B5A062@SJCEML701-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [133.93.24.147]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/icnrg/DrP93K9sz7iS90k5Lz4WDo5Bbg4>
Subject: Re: [icnrg] New Version Notification for draft-ravi-ccn-forwarding-label-01.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Nov 2015 00:41:15 -0000

Here are some comments following up on the session meeting.


- General comments
-- Several places the draft says "there may be cases" or
   something similar.  I think to be implementable, everything
   needs to be spelled out in more detail.  make a state machine
   or flow chart or pseudocode or something.

- Section (forwarding): Layout 3 approaches, but when to use them?
-- can you intermix?
-- It seems like this needs correctness and liveness proofs

- Section 4: bulleted items
-- says the apply to approach 1, but really they apply to any
   approach that is forwarding on the LID.

-- Bullet #1 seems duplicative of case 1 vs cases 2+3.

-- Bullet #2, how will an intermediate system know the
   application is in the same trust domain?
   -- Answer: You put an additional field in the packet.  You
      need to say this in the draft and spell out how it works.

-- Bullet #4: think the fallback lookup needs analysis as
   mentioned above.

- Section 5 (pit):

-- Seems like a complex way to say that if a forwarder swaps
   the LID, it needs to reverse-swap the LID on the way back.

-- It seems like the way the PIT operates has to be tied to how
   the forwarding operates and these need to be correlated not
   just "in some cases".

- Security attributes:

-- I think and example or more explanation is needed not just
   citing reference [1].

Marc

________________________________________
From: icnrg [icnrg-bounces@irtf.org] on behalf of Ravi Ravindran [ravi.ravindran@huawei.com]
Sent: Wednesday, November 04, 2015 1:21 PM
To: icnrg@irtf.org
Subject: [icnrg] FW: New Version Notification for draft-ravi-ccn-forwarding-label-01.txt

Published version of the forwarding-label draft.

Regards,
Ravi

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, November 04, 2015 12:53 PM
To: Asit Chakraborti; Ravi Ravindran; Ravi Ravindran
Subject: New Version Notification for draft-ravi-ccn-forwarding-label-01.txt


A new version of I-D, draft-ravi-ccn-forwarding-label-01.txt
has been successfully submitted by Ravishankar Ravindran and posted to the
IETF repository.

Name:           draft-ravi-ccn-forwarding-label
Revision:       01
Title:          Forwarding-Label support in CCN Protocol
Document date:  2015-11-03
Group:          Individual Submission
Pages:          11
URL:            https://www.ietf.org/internet-drafts/draft-ravi-ccn-forwarding-label-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ravi-ccn-forwarding-label/
Htmlized:       https://tools.ietf.org/html/draft-ravi-ccn-forwarding-label-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ravi-ccn-forwarding-label-01

Abstract:
   The objective of this proposal is to enable ID/Locator split in CCN
   protocol.  We enable this through the notion of forwarding-label (FL)
   object, which is an optional hop-by-hop payload in the Interest
   message with locator name which identifies a network domain, router,
   or a host.  Depending on the application and trust context FL object
   is subjected to policy based actions by the forwarders such as
   invoking security verification or enabling other service-centric
   actions such as FL object replacement.  FL can be inserted by the
   applications or by the network.  To enable dynamic name resolution FL
   can be modified in the network by designated points such as the edge
   routers.  Enabling ID/Locator split in CCN has several applications
   such as towards routing optimization, mobility, handling indirections
   in manifests, and routing scalability.




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
icnrg@irtf.org
https://www.irtf.org/mailman/listinfo/icnrg