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

From: "roll issue tracker" <[email-masked]>
Date: Wed, 04 Apr 2012 13:11:44 -0000

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

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 8 Apr 2012 11:08:58 -0500 (CDT)

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" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Wednesday, April 4, 2012 8:11:44 AM
Subject: [roll] #90: use of transient instance ID

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 10 Apr 2012 11:52:50 +0200

Mukul:

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.

Cheers,

Pascal

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

Hi Pascal

" [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" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Wednesday, April 4, 2012 8:11:44 AM
Subject: [roll] #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

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 10 Apr 2012 20:39:03 -0500 (CDT)

Hi Pascal

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

Sounds good.

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

Not sure what you mean. 

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

Cheers,

Pascal

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

Hi Pascal

Thanks
Mukul

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

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 11 Apr 2012 08:14:52 +0200

Hello Mukul:

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

[Mukul] Not sure what you mean. 

[Pascal2] Let me reword:  if HbH routin gis not used, the only states with any persistence are on the origin and target(s). The upper layer protocol (ULP) in origin and target may know when they are done with their need for the routes. If they are done before (config option) lifetime is up, they can tear down the states. This requires a new cross layer interaction triggered by ULP, similar to IPv6 ND in DELAY state.

Cheers,

Pascal

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

Cheers,

Pascal

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

Hi Pascal

Thanks
Mukul

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

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Apr 2012 05:07:35 -0500 (CDT)

Hi Pascal

Please see inline.

Thanks
Mukul

[Mukul2]
You think P2P-RPL needs to define this cross-layer interaction? This is simply the upper layer telling the network layer to chuck a source route. Isn't it? The upper/lower layers dont even need to remember that this route was discovered using P2P-RPL. Also, the origin (or the target) can use a source route as long as it wants. Why should the lifetime in config option dictate how long this route can be used?

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

Cheers,

Pascal

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

Hi Pascal

Thanks
Mukul

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

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Apr 2012 08:13:14 +0200

Hi Mukul

Don't worry! For the upper layers interaction I'm only asking for one sentence, not an API spec... Like:
 
"The required lifetime for the routing states may be provided by the application via a hint from upper-layer protocols. Additional hints from upper-layer protocols can be used to tear down the remaining states at the origin and/or at the target as soon the application need of those states is terminated or the application detects that the states are not functional anymore. In a same fashion, an interaction with upper layers can be used to determine that the routing states are still valid and can be prolonged for an additional lifetime"

That's all!

For your questions please see inline. Also, as an example of existing art, RFC 4861 stays as abstract as I do above with text like:

      DELAY       The neighbor is no longer known to be reachable, and
                  traffic has recently been sent to the neighbor.
                  Rather than probe the neighbor immediately, however,
                  delay sending probes for a short while in order to
                  give upper-layer protocols a chance to provide
                  reachability confirmation.

...

7.3.1. Reachability Confirmation

   A neighbor is considered reachable if the node has recently received
   a confirmation that packets sent recently to the neighbor were
   received by its IP layer.  Positive confirmation can be gathered in
   two ways: hints from upper-layer protocols that indicate a connection
   is making "forward progress", or receipt of a Neighbor Advertisement
   message that is a response to a Neighbor Solicitation message.

Pascal

-----Original Message-----

[Mukul2]

[Pascal3] In IPv6, by design, everything has a lifetime. Better fix this now than during IESG review. In the case of this draft, nodes commit resources which are by definition limited. Thus in the general case that the draft addresses they can't commit those resources forever. One end point might die, say out of battery. There must be something that in any case will ensure that all parties, end points and intermediate routers in HbH end up clean even if there is no (rst) signaling to achieve so. 

You can pick a large lifetime if you like for the light switch you have in mind; but there needs to be a lifetime, after which states must be revalidated. That can be rebuilding the DAG, this can be unicast like a ping, and this can by piggy backed with traffic. ND for instance uses upper layer hints to validate that the reachability without necessarily signaling everything. Since you are going for experimental, I'm asking for the bare minimum, a simple lifetime using existing means (the config option). 

 If an application is responsible for setting up routing states, this application may also be clever enough to provide a hint on the lifetime, and to tear down the states that it caused when it does not need them anymore. If the application does not provide any hint whatsoever, the implementation at the origin will select a reasonable lifetime that will depend on the function of the object. I'm certainly not asking to define the interaction between upper layer and L3, this is internal and thus implementation.

 Cheers,

Pascal

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

Cheers,

Pascal

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

Hi Pascal

Thanks
Mukul

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

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 13 Apr 2012 03:19:58 -0500 (CDT)

Hi Pascal

1.) I propose adding the following text at the end of Section 9.6 (Processing a DRO at an Intermediate Router) in P2P-RPL spec:

"The hop-by-hop routing state established on receiving a DRO MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery.
A future version of this document may consider specifying a signalling mechanism that will allow the origin to extend (or shorten)
the lifetime of a P2P-RPL hop-by-hop route following a suitable hint from an upper-layer protocol."

2.) I propose replacing the following text in Section 9.5 (Additional Processing of a P2P mode DIO at the Target):

"The target MAY store the route contained in the P2P-RDO in the received DIO for use as a source route to reach the origin."

with the following text:

"The target MAY store the route contained in the P2P-RDO in the received DIO for use as a source route to reach the origin. The lifetime of this source route is specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option in the received DIO. This lifetime can be extended (or shortened) appropriately following a suitable hint from an upper-layer protocol."

3.) I propose replacing the following text in Section 9.7 (Processing a DRO at the Origin):

"If the P2P-RDO inside the DRO identifies the discovered route as a source route (H=0), the origin MUST store in its memory the
   discovered route contained in the Address vector."

with the following text:

"If the P2P-RDO inside the DRO identifies the discovered route as a source route (H=0), the origin MUST store in its memory the
   discovered route contained in the Address vector. The lifetime of this source route is specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. This lifetime can be extended (or shortened) appropriately following a suitable hint from an upper-layer protocol."

4.) One consequence of these changes is that the intermediate router or the origin MUST still belong to the temporary DAG in order to process a received DRO. This is because the intermediate router (or the origin) needs to know the lifetime (contained in the config option) to be associated with the HbH/source routing state it would establish on processing the DRO.

Can we now consider the issue closed?

Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked]
Sent: Thursday, April 12, 2012 1:13:14 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Hi Mukul

That's all!

...

Pascal

-----Original Message-----

[Mukul2]

 Cheers,

Pascal

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

Cheers,

Pascal

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

Hi Pascal

Thanks
Mukul

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

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Apr 2012 10:37:38 +0200

Hello Mukul

"The hop-by-hop routing state established on receiving a DRO MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery.
A future version of this document may consider specifying a signalling mechanism that will allow the origin to extend (or shorten) the lifetime of a P2P-RPL hop-by-hop route following a suitable hint from an upper-layer protocol."

[Pascal] Since we're shooting for experimental I'm fine with this. We'll have to effectively consider the mentioned addition when going standard track.

with the following text:

[Pascal] Works for me

with the following text:

[Pascal] Works for me

[Pascal] Which is a constraint that you place on the admin that chooses the temporary DAG lifetime.  And there'll probably be a well-known default so that the config option is not required in which case storing that state is not required either. You may want a sentence to say that...

[Pascal] yes, we can. (I always dreamed of saying this...)
 
Thanks
Mukul

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked]
Sent: Thursday, April 12, 2012 1:13:14 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Hi Mukul

That's all!

...

Pascal

-----Original Message-----

[Mukul2]

 Cheers,

Pascal

----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, April 10, 2012 4:52:50 AM
Subject: RE: [Roll] [roll] #90: use of transient instance ID

Mukul:

Cheers,

Pascal

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

Hi Pascal

Thanks
Mukul

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

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

 [Pascal]

 [Mukul]

 [Mukul4] OK.

 Pascal

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 13 Apr 2012 09:02:30 -0000

Changes (by jpv@…):

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

Comment:

 Hello Mukul

 1.) I propose adding the following text at the end of Section 9.6
 (Processing a DRO at an Intermediate Router) in P2P-RPL spec:

 "The hop-by-hop routing state established on receiving a DRO MUST expire
 at the end of the lifetime specified by the Default Lifetime and Lifetime
 Unit parameters inside the DODAG Configuration Option used in P2P mode
 DIOs for this route discovery.
 A future version of this document may consider specifying a signalling
 mechanism that will allow the origin to extend (or shorten) the lifetime
 of a P2P-RPL hop-by-hop route following a suitable hint from an upper-
 layer protocol."

 [Pascal] Since we're shooting for experimental I'm fine with this. We'll
 have to effectively consider the mentioned addition when going standard
 track.

 2.) I propose replacing the following text in Section 9.5 (Additional
 Processing of a P2P mode DIO at the Target):

 "The target MAY store the route contained in the P2P-RDO in the received
 DIO for use as a source route to reach the origin."

 with the following text:

 "The target MAY store the route contained in the P2P-RDO in the received
 DIO for use as a source route to reach the origin. The lifetime of this
 source route is specified by the Default Lifetime and Lifetime Unit
 parameters inside the DODAG Configuration Option in the received DIO. This
 lifetime can be extended (or shortened) appropriately following a suitable
 hint from an upper-layer protocol."

 [Pascal] Works for me

 3.) I propose replacing the following text in Section 9.7 (Processing a
 DRO at the Origin):

 "If the P2P-RDO inside the DRO identifies the discovered route as a source
 route (H=0), the origin MUST store in its memory the
   discovered route contained in the Address vector."

 with the following text:

 "If the P2P-RDO inside the DRO identifies the discovered route as a source
 route (H=0), the origin MUST store in its memory the
   discovered route contained in the Address vector. The lifetime of this
 source route is specified by the Default Lifetime and Lifetime Unit
 parameters inside the DODAG Configuration Option used in P2P mode DIOs for
 this route discovery. This lifetime can be extended (or shortened)
 appropriately following a suitable hint from an upper-layer protocol."

 [Pascal] Works for me

 4.) One consequence of these changes is that the intermediate router or
 the origin MUST still belong to the temporary DAG in order to process a
 received DRO. This is because the intermediate router (or the origin)
 needs to know the lifetime (contained in the config option) to be
 associated with the HbH/source routing state it would establish on
 processing the DRO.

 [Pascal] Which is a constraint that you place on the admin that chooses
 the temporary DAG lifetime.  And there'll probably be a well-known default
 so that the config option is not required in which case storing that state
 is not required either. You may want a sentence to say that...

 Thanks
 Mukul

 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" <[email-masked]>
 To: "Mukul Goyal" <[email-masked]>
 Cc: [email-masked]
 Sent: Thursday, April 12, 2012 1:13:14 AM
 Subject: RE: [Roll] [roll] #90: use of transient instance ID

 Hi Mukul

 Don't worry! For the upper layers interaction I'm only asking for one
 sentence, not an API spec... Like:

 "The required lifetime for the routing states may be provided by the
 application via a hint from upper-layer protocols. Additional hints from
 upper-layer protocols can be used to tear down the remaining states at the
 origin and/or at the target as soon the application need of those states
 is terminated or the application detects that the states are not
 functional anymore. In a same fashion, an interaction with upper layers
 can be used to determine that the routing states are still valid and can
 be prolonged for an additional lifetime"

 That's all!

 For your questions please see inline. Also, as an example of existing art,
 RFC 4861 stays as abstract as I do above with text like:

 ...

 Pascal

 -----Original Message-----

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

 [Pascal2] Let me reword:  if HbH routin gis not used, the only states with
 any persistence are on the origin and target(s). The upper layer protocol
 (ULP) in origin and target may know when they are done with their need for
 the routes. If they are done before (config option) lifetime is up, they
 can tear down the states. This requires a new cross layer interaction
 triggered by ULP, similar to IPv6 ND in DELAY state.

 [Mukul2]
 You think P2P-RPL needs to define this cross-layer interaction? This is
 simply the upper layer telling the network layer to chuck a source route.
 Isn't it? The upper/lower layers dont even need to remember that this
 route was discovered using P2P-RPL. Also, the origin (or the target) can
 use a source route as long as it wants. Why should the lifetime in config
 option dictate how long this route can be used?

 [Pascal3] In IPv6, by design, everything has a lifetime. Better fix this
 now than during IESG review. In the case of this draft, nodes commit
 resources which are by definition limited. Thus in the general case that
 the draft addresses they can't commit those resources forever. One end
 point might die, say out of battery. There must be something that in any
 case will ensure that all parties, end points and intermediate routers in
 HbH end up clean even if there is no (rst) signaling to achieve so.

 You can pick a large lifetime if you like for the light switch you have in
 mind; but there needs to be a lifetime, after which states must be
 revalidated. That can be rebuilding the DAG, this can be unicast like a
 ping, and this can by piggy backed with traffic. ND for instance uses
 upper layer hints to validate that the reachability without necessarily
 signaling everything. Since you are going for experimental, I'm asking for
 the bare minimum, a simple lifetime using existing means (the config
 option).

 If an application is responsible for setting up routing states, this
 application may also be clever enough to provide a hint on the lifetime,
 and to tear down the states that it caused when it does not need them
 anymore. If the application does not provide any hint whatsoever, the
 implementation at the origin will select a reasonable lifetime that will
 depend on the function of the object. I'm certainly not asking to define
 the interaction between upper layer and L3, this is internal and thus
 implementation.

 Cheers,

 Pascal

 ----- Original Message -----
 From: "Pascal Thubert (pthubert)" <[email-masked]>
 To: "Mukul Goyal" <[email-masked]>, [email-masked]
 Sent: Tuesday, April 10, 2012 4:52:50 AM
 Subject: RE: [Roll] [roll] #90: use of transient instance ID

 Mukul:

 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.

 Cheers,

 Pascal

 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]] On Behalf Of
 Mukul Goyal
 Sent: dimanche 8 avril 2012 18:09
 To: [email-masked]
 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.

 Thanks
 Mukul

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

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

 [Pascal]

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

 [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:  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/90#comment:1>
roll <http://tools.ietf.org/wg/roll/>