Re: [Roll] [roll] #88: Data option and ULP

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Fri, 13 April 2012 09:47 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2521F84CF for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 02:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.463
X-Spam-Level:
X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO9uPA9aIoPz for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 02:47:06 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5891621F84C8 for <roll@ietf.org>; Fri, 13 Apr 2012 02:47:05 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1SIchG-0003kI-JZ; Fri, 13 Apr 2012 05:21:38 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: roll issue tracker <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:21:37 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/88#comment:1
Message-ID: <070.3a780a7501735afacd820d142eb72143@trac.tools.ietf.org>
References: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org>
X-Trac-Ticket-ID: 88
In-Reply-To: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #88: Data option and ULP
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 09:47:07 -0000

#88: Data option and ULP

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Mukul,

 I agree with this resolution. We can close the ticket and I'll review the
 text once you publish.

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:mukul@uwm.edu]
 Sent: jeudi 12 avril 2012 04:40
 To: roll@ietf.org
 Cc: JP Vasseur; Pascal Thubert (pthubert)
 Subject: Closure text for ticket #88


 #88: Data option and ULP

 Problem
 ------------------------------
 An option exists for carrying payload. The use of the option (tunnel,
 transport?) is not described properly.

 Resolution
 ------------------------
 Add a next header and a sequence to the data option so upper layers can
 be determined.

 Discussion
 -------------

 [Pascal]
 Can the data option be different from one DIO to the next?

 [Mukul]
 The contents of the data option are specified by the origin (for the
 DIO) or the target (for the DRO). In theory, an origin can send  different
 data options in different DIOs it generates for a particular  route
 discovery (assuming that it does generate multiple DIOs; it is  very much
 possible that the origin generates just one DIO and then sits  silent).
 But, then the origin is taking the risk that some of the data  options
 would never each the target(s). I guess the origin might do this  if the
 data sent earlier is now stale and the origin would like the
 target(s) to receive newer data.


 [Pascal2] This should be discussed in the draft. You need to set the
 expectation for the upper layer(s). Is there a way to differentiate
 different data sets? Eg instance or sequence nb?
 My suggestion so far is that the data should have 3 bits of next header
 and 5 bits of sequence.

 [Mukul2] This sounds good to me. I will incorporate this in the draft
 unless I hear a better proposal.

 [Pascal3] Cool. Please make that another LC issue and the proposed
 resolution, see if there is anyone adding anything to it.

 [Mukul3] Actually, I would like the next header to be 4 bits and the
 sequence number to be 4 bits. 4-bit sequence number will still allow up
 to 16 different messages to be sent during a P2P-RPL discovery. 4 bit
 next header will allow 16 different possibilities. We can have so many
 different ways to compress UDP/TCP headers. I think 3 bit next header  may
 not be sufficient.

 [Pascal4] Cool. Let's use that as the proposed resolution

 _______________________________________________
 Roll mailing list
 Roll@ietf.org
 https://www.ietf.org/mailman/listinfo/roll

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/88#comment:1>
roll <http://tools.ietf.org/wg/roll/>