Re: [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.

Changes (by jpv@…):

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


Comment:

 Hi Mukul

 Perfect. As far as I'm concerned we can close this one...

 <to the ML> Mukul and I had a call where we fixed our disconnect.
 Mukul's proposal below addresses the issue that I had in mind - as opposed
 to the issue that he thought I had in mind and that BTW we agreed was not
 an issue...

 Cheers,

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:[e-mail]]
 Sent: vendredi 13 avril 2012 09:03
 To: Pascal Thubert (pthubert)
 Cc: [e-mail]; roll
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Pascal

 Now we are on the same page. I propose that the following text in section
 6.1 of P2P-RPL spec:

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

 "

 be replaced by the following text:

 "The origin sets the Default Lifetime and Lifetime Unit parameters in
 DODAG Configuration option to indicate the life time of the state the
 routers, including the origin and the target(s), maintain for a hop-by-hop
 or a source route discovered using P2P-RPL.
 "

 Thanks
 Mukul


 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" <[e-mail]>
 To: "Mukul Goyal" <[e-mail]>
 Cc: [e-mail], "roll" <[e-mail]>
 Sent: Wednesday, April 11, 2012 1:22:52 AM
 Subject: RE: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Mukul:

 We have a disconnect because you insist in thinking that I refer to the
 lifetime of the temporary DAG as indicated in the RDO.
 But no. I reworded twice and used very specific words this last time.
 Please remove the temp Dag from the discussion and read again in the light
 that I'm really talking about the states HbH routing states as I very
 specifically indicate.
 If that does not work then we'll need a phone call to resync.

 Cheers,

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:[e-mail]]
 Sent: mercredi 11 avril 2012 01:59
 To: Pascal Thubert (pthubert)
 Cc: [e-mail]; roll
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Pascal

 I do not wish to change the DAG lifetime.

 I'm pointing out that the conversation between the origin and target
 cannot work longer than the lifetime of the "hop-by-hop routing states"
 which it depends on. So why not use that?

 You mean state about the "temporary DAG" and not the hop-by-hop state for
 the "discovered route"? They are two different things.

 I suggest that we converge the time duration specified in DODAG
 configuration option to mean the maximum duration of states in all nodes
 that need to keep states, including origin and target, and in some case
 intermediate routers.

 We are using the time duration in DODAG configuration option to specify
 the lifetime of the "hop-by-hop state for the discovered route" (and not
 the lifetime of the "temporary DAG"). A discovered HbH route may need to
 be maintained for a wide range of time durations. Hence, we would like to
 specify the lifetime of a discovered route using the rich semantics
 provided by the time duration fields inside the DODAG configuration
 option. On the other hand, the lifetime of a temporary DAG does not need
 to vary a whole lot. So, we provide 4 options for this lifetime (1, 4, 16
 and 64 seconds) and specify this lifetime in a 2-bit field inside P2P-RDO.

 Do you agree with how the two lifetimes (lifetime of DAG and lifetime of
 the discovered route) are specified in P2P-RPL?

 IOW, if the HbH route is used, the lifetime in the config option is for
 all states in all nodes on the path(s) including origins and target(s). If
 HbH routing is not used, the lifetime in the config option is still valid
 for the source and the origin. You may define a default value that suit
 classical P2P routes in the case where no config of any sort is provided.

 You seem to want the config option to specify the lifetime of the
 temporary DAG. This would be a wastage of rich semantic provided by those
 fields. If you could agree to specifying the temporary DAG lifetime inside
 P2P-RDO (the way P2P-RPL currently does), I see no problem whatsoever. All
 nodes (including the origin and target) joining the temporary DAG maintain
 state for the temporary DAG (which is not same as the state for the
 discovered HbH route) for the duration specified in P2P-RDO. We could
 further require that all DRO/DRO-ACK exchange MUST complete within the
 temporary DAG lifetime (specified inside P2P-RDO). So, the temporary DAG's
 lifetime has to be chosen carefully. Having said that, I still prefer
 giving origin and target extra time (equal to one more lifetime) to
 complete DRO/DRO-ACK exchange.

 Thanks
 Mukul

 And yes, great point, you'd need to specify that the lifetime in the
 config option must be large enough to accommodate the retransmissions.

 Do we converge?

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:[e-mail]]
 Sent: mardi 10 avril 2012 14:55
 To: Pascal Thubert (pthubert)
 Cc: [e-mail]; roll
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 OR the simpler option would be to require DRO/DRO-ACK exchange to complete
 within the DAG's life time? If we were to specify a new parameter for the
 time limit on DRO/DRO-ACK exchange, both target and origin would need to
 agree on the value of this parameter.

 Mukul

 ----- Original Message -----
 From: "Mukul Goyal" <[e-mail]>
 To: "Pascal Thubert (pthubert)" <[e-mail]>
 Cc: [e-mail], "roll" <[e-mail]>
 Sent: Tuesday, April 10, 2012 7:50:16 AM
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Pascal

 Hopefully we are talking about the same thing.

 No, it's not closed. We are talking about a contract between lower layers
 in all nodes including the source and origin to maintain necessary
 resources and all contracts must have a lifetime.

 1. A node that joins a temporary P2P-RPL DAG maintains state for the DAG
 for the time duration specified as DAG life time.
 2. A node that establishes hop-by-hop routing state for a route discovered
 using P2P-RPL maintains this state for the time duration specified in
 DODAG configuration option.

 Origin and target need to exchange DROs and DRO-ACKs. I could specify a
 new configurable parameter to specify the time limit on this exchange.
 This parameter's value  has to be more than DAG life time. One option is
 to specify it in terms of existing parameters: DAG life time +
 (MAX_DRO_RETRANSMISSIONS + 1)*DRO_ACK_WAIT_TIME.

 Thanks
 Mukul
 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" <[e-mail]>
 To: "Mukul Goyal" <[e-mail]>
 Cc: [e-mail]
 Sent: Tuesday, April 10, 2012 4:45:46 AM
 Subject: RE: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Hi Mukul,

 No, it's not closed. We are talking about a contract between lower layers
 in all nodes including the source and origin to maintain necessary
 resources and all contracts must have a lifetime.
 I do not mind you overload the RPL lifetime of the routing for the states
 at origin and target and if you have a sentence that makes it clear then
 we'll be in agreement.

 Cheers,

 Pascal


 -----Original Message-----
 From: Mukul Goyal [mailto:[e-mail]]
 Sent: dimanche 8 avril 2012 17:52
 To: Pascal Thubert (pthubert)
 Cc: [e-mail]
 Subject: Re: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 Pascal

 Can we consider this issue closed? Please see my last response.

 Thanks
 Mukul

 ----- Original Message -----
 From: "roll issue tracker" <[e-mail]>
 To: [e-mail], [e-mail]
 Cc: [e-mail]
 Sent: Wednesday, April 4, 2012 8:06:30 AM
 Subject: [roll] #85: which lifetime is for the end points (origin and
 target) vs. intermediate nodes.

 #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/>

 _______________________________________________
 Roll mailing list
 [e-mail]
 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/85#comment:1>
roll <http://tools.ietf.org/wg/roll/>