Re: [Roll] [roll] #90: use of transient instance ID

"Pascal Thubert (pthubert)" <> Tue, 10 April 2012 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E96A111E8072 for <>; Tue, 10 Apr 2012 02:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.994
X-Spam-Status: No, score=-9.994 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id voNjl14qhZ6H for <>; Tue, 10 Apr 2012 02:53:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9DE3F21F86DE for <>; Tue, 10 Apr 2012 02:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6512; q=dns/txt; s=iport; t=1334051587; x=1335261187; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=pQNAuxBZXPB60+P/aFeOYvHtQfnkwswWhDMYwNdGugI=; b=FD7SgEWmDujZPszo+fkBsInO751HIeerm1YEb5HB1dQXWoh1JjbnMyDb bgFZzqMgtQ+SxQ22bpeHXCsW0vd+iHIUpJL32oo43ItcjzhqUjOGftTYR kSfYWw80ZIYWrPSmnNSBpzh+pyR8N1Zrf3Gfn269tNgSxHOntKBoyFMEF Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.75,398,1330905600"; d="scan'208";a="134682572"
Received: from ([]) by with ESMTP; 10 Apr 2012 09:53:06 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q3A9r6Q8017627; Tue, 10 Apr 2012 09:53:06 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 11:53:06 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Date: Tue, 10 Apr 2012 11:52:50 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [Roll] [roll] #90: use of transient instance ID
Thread-Index: Ac0Vof4x3Pqwjs5MSOSMfmzhGKSdwgBXRWRQ
References: <> <>
From: "Pascal Thubert (pthubert)" <>
To: Mukul Goyal <>,
X-OriginalArrivalTime: 10 Apr 2012 09:53:06.0428 (UTC) FILETIME=[BA747BC0:01CD16FF]
Subject: Re: [Roll] [roll] #90: use of transient instance ID
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Apr 2012 09:53:09 -0000


I meant a suggestion, not a capitalized word. I prefer the suggestion but I'm still OK with your proposal. If we get in agreement on the lifetime of the states (issue #85), then you can indicate that lifetime is one way to determine when all stale states can be considered gone. Also, when there are no routing states in intermediate routers, an indication from upper layers can be used in the end points to consider that all states for an instanceID are now cleaned up.



-----Original Message-----
From: [] On Behalf Of Mukul Goyal
Sent: dimanche 8 avril 2012 18:09
Subject: Re: [Roll] [roll] #90: use of transient instance ID

Hi Pascal

Re-read your proposed resolution text. I am not sure that the draft should suggest rotating the instance ids. My proposed resolution is to simply suggest not using instance id that might be in use.

" [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  in the nodes."


----- Original Message -----
From: "roll issue tracker" <>
To: mukul@UWM.EDU,
Sent: Wednesday, April 4, 2012 8:11:44 AM
Subject: [roll] #90: use of transient instance ID

#90: use of transient instance ID

 Problem (resolution agreed upon)
 P2P creates temporary states in the transient DAG with a transient  instance ID. The protocol must ensure that if the instance ID is reused  then the new operation it is not confused with states resulting from the  previous use of the same instance ID. Suggestion is to propose a  rotation.


 "RPLInstanceID: RPLInstanceID MUST be a local value as described in  Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the same  RPLInstanceID in two or more concurrent route discoveries."

 I'd suggest that you enforce a round robin or an opaque circulation so  that the new instanceID is the least recently used one out of the 64  possible.

 I think we should leave it to the origin to decide which value it wants  to use for RPLInstanceID. I know some implementations are planning to  use a fixed RPLInstanceID value for all route discoveries.

 [Pascal2] Changing the instance ID will help debug the network and avoid  conflicts with stale states. What's really up to the device is the  initial sequence. Leaving it up to the origin may help the origin defeat  some attacks to some degree. OTOH, after all the instances have been  played, LRU forces to replay the same sequence again so the shield  drops. My preferred approach would be a SHOULD that would say that the  next instance ID SHOULD NOT be one of the (16?) most recently used and  MUST NOT be one for which states might still exist in the network. IOW  either the states deletion was acknowledged, or all pending lifetimes  are exhausted.

 [Mukul2] Makes sense. I think it is sufficient to caution (with a SHOULD
 NOT) against reusing instance ids for which the stale state might exist  in the nodes. Using a "MUST NOT" may not be OK since a node may never be  100% sure about non-existence of stale state with a particular instance  id (thus, all possible instance id values will become suspect and hence  unusable after a while).

 [Pascal3] Agreed. Note that a circulation is a bonus to defeat replays.
 And now we're back to the issue above. How does the device know that  there is no state left? A lifetime definition would be very useful. That  lifetime is different from the DAG's one in RDO. I think we have an open  issue here.

 [Mukul3] As I mentioned above, the life time parameters inside the DODAG  configuration option specify the life time of the hop-by-hop routing  state for the routes discovered using P2P-RPL.

 [Pascal4] This boils down to the thread above. Only one issue really,  which lifetime is which? So IMHO no need to log anything for this  thread.

 [Mukul4] OK.


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

Ticket URL: <>
roll <>

Roll mailing list