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

Thanks for the comments Marc, we discussed few of these during the presentation. But to benefit others, from the last draft, we tried to make this more broad to lay out the open questions when such a feature is enabled, and most of the use of 'May' comes from accommodating applications (consumers) to use this feature too. 

So one of the possible extension of the draft is use to tie it to a specific scenario, specifically when FL is used only by the infrastructure, and be more specific on the management and processing details.

Regards,
Ravi

-----Original Message-----
From: Marc.Mosko@parc.com [mailto:Marc.Mosko@parc.com] 
Sent: Thursday, November 05, 2015 9:41 AM
To: Ravi Ravindran; icnrg@irtf.org
Subject: RE: New Version Notification for draft-ravi-ccn-forwarding-label-01.txt

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