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

[Mukul Goyal <[e-mail]>]

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."

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
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.

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

 [Pascal]
 "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.

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

 Pascal

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

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/90>
roll <http://tools.ietf.org/wg/roll/>