[Roll] [roll] #85: which lifetime is for the end points (origin and target) vs. intermediate nodes.

["roll issue tracker" <[e-mail]>]

#85: which lifetime is for the end points (origin and target) vs. intermediate
nodes.

 Problem (currently open)
 ------------------------------
 P2P creates temporary states in the transient DAG and less-but-still
 temporary states in the endpoints. These are 2 different lifetimes. The
 spec has 2 lifetimes, one in the config option and one in the RDO. The
 spec is not sufficiently clear about which is which. In can appear to be
 conflicting since the config option is supposed to apply to all routers
 on the path. On the side, and in order to allow the reuse of instance
 ID, the origin must be sure that all states for a previous usage of the
 same value are gone. So we need a clear control / negotiation of the
 lifetimes on the states that come with an instanceID. Again this is not
 clear enough in the spec.



 [Pascal2]
 2) Same question if you want to create states at the target to route
 back. How long does the target need to maintain the route? Who controls
 that, the origin or the target? I'd expect to find a suggested lifetime
 in the RDO with a confirmation in the DRO to let the target amend it.

 [Mukul2]
 If the target wants DRO-ACK it needs to maintain state until DRO-ACK is
 received. Otherwise, the target needs to remember things until it is
 done sending all the DROs. I will add the text to this effect.

 [Pascal3]
 If you are setting up a short term conversation, how long exactly is
 that before the origin has to refresh the route? What controls clean up
 in both sides? Usually you want a lifetime (see MIP6 for instance)

 [Mukul3]
 Is it that you are talking about the lifetime of the hop-by-hop routing
 state? That is specified in the life time parameters in the DODAG
 configuration option. The draft says that on page 9 while describing how
 the DODAG configuration option should be set inside a P2P mode DIO:

 "The Default Lifetime and Lifetime Unit parameters in DODAG
      Configuration option indicate the life time of the state the
      routers maintain for a hop-by-hop route established using P2P-RPL
      and may be set as desired.
 "

 [Pascal4] Maybe that's so but then you need to reword a little bit cause
 you got me qiute confused. I've been talking of the lifetime of the
 states at origin and target for one conversation. Since they might be
 having a transient conversation, and the origin might reuse the instance
 ID soon, you need to give a limit in time to the states that you are
 creating. Still that conversation is longer than the states in the
 intermediate routers. So you have 2 lifetimes and you have to be very
 clear which is which. Personally, I'd have used the lifetime in the
 configuration option for all the routers on the way and I'd have used
 the new lifetime in the RDO as the conversation lifetime in the end
 points because:
 1)  that is the new concept.
 2) This would allow the target to confirm exactly how long it locks
 resources,
 3) and this would be more compatible with the description of the config
 option in RFC 6550.

 [Mukul4]
 There are two lifetimes:
 1) Lifetime of the temporary DAG: this is specified inside P2P-RDO
 2) Lifetime of the routing state for the hop-by-hop route established
 using P2P-RPL: this is specified inside the DODAG configuration option.
 All routers on the established route (including the origin) maintain
 state for this route for this much time. This time could very well be
 infinity.

 Now, lets talk about the "states at origin and target". The origin and
 the target maintain the state about the temporary DAG for the DAG's life
 time. This is true for all the nodes that join this DAG. All such nodes
 maintain state about the temporary DAG until the DAG's life time is
 over. It is true that the target and the origin exchange DROs and
 DRO-ACKs and this exchange could conceivably go on even after the
 temporary DAG's demise. How long should the origin and target indulge in
 this exchange (and hence remember the possibly dead DAG)? I think it is
 purely their choice and the draft need not impose any artificial time
 limit on this.

 Pascal

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

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/85>
roll <http://tools.ietf.org/wg/roll/>