Subject: Re: [Roll] Part 2 Re: G.RE: ROLL WG Last Call on draft-ietf-roll-p2p-rpl-09

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 1 Apr 2012 09:40:29 +0200

Hi Mukul:

I think we need to create a number of last call issues for tracking purpose. Everything I snipped off is an implicit acceptance of your response...

*******************************************************************

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

*************************************************************************************

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

****************************************************************************************

[Pascal]
" Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing."

On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG.

[Mukul]
Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero.

[Pascal2] Please revisit RFC 6650 page 12. 
G means that a goal is achieved. So first you define the goal and then the bit becomes obvious. What's your goal? 
Can there be P2P DAGs that achieve the goal and others that make sense to build and yet do not achieve the goal?
If you accept that your operation can actually depend on OF logic, then the setting of the goal influences that logic.
By forcing a value to the goal in the PTP spec, we actually limit the applicability of the draft. 
Maybe you can define a default goal and a default setting. But do not MUST that it is set to 0...

[Mukul2]
When a node joins a temporary P2P DAG, it does not get any additional routing information. The DAG is going to disappear after some time, should not be used for routing while it exists and which nodes end up being on the discovered route is not known until the DRO message comes back. So, I think, by default, the G flag has to be zero. However, if the setting of G flag may affect how an intermediate node may calculate its rank (as per the OF being used), the origin should have the flexibility of setting the flag to 1. So, I could modify the text to say that "the origin sets the G flag based on its perception of how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created."

[Pascal2] Why do you feel the need to add anything above what RFC 6550 says? I do not see any benefit or additional clarity from doing this.

****************************************************************************************

[Pascal]" MAY carry one or more RPL Target Options to specify additional unicast/multicast addresses for the target."
Now here I would have a MUST carry at least one target. That is indeed what makes is a lookup DIO...

[Mukul]
As I stated in the previous message, we need to include the target in the P2P-RDO to save bytes for the common case (discover route to one unicast/multicast target). So, we cannot make using the target option a MUST.

[Pascal2] Certainly. I prefer the split, in which case the MUST IMHO goes to the target as opposed to the RDO. In a case where the RDO is not needed, the target only message is actually shorter...

[Mukul2] As I said before, I think a P2P mode DIO always needs to have one P2P-RDO. I guess, in this case, we agree to disagree!

[Pascal3] Certainly. And there's nothing blocking with that disagreement, mostly if the draft targets experimental. 
 I think it's OK to keep your response as the proposed resolution for the issue. Still I'd like advice from others so exposing the issue as LC will help. Let's see on which side the coin falls.

************************************************************************************************
[Pascal]
Can the data option be different from one DIO to the next? 

[Mukul]
The contents of the data option are specified by the origin (for the DIO) or the target (for the DRO). In theory, an origin can send different data options in different DIOs it generates for a particular route discovery (assuming that it does generate multiple DIOs; it is very much possible that the origin generates just one DIO and then sits silent). But, then the origin is taking the risk that some of the data options would never each the target(s). I guess the origin might do this if the data sent earlier is now stale and the origin would like the target(s) to receive newer data.

[Pascal2] This should be discussed in the draft. You need to set the expectation for the upper layer(s). Is there a way to differentiate different data sets? Eg instance or sequence nb?
My suggestion so far is that the data should have 3 bits of next header and 5 bits of sequence.

[Mukul2] This sounds good to me. I will incorporate this in the draft unless I hear a better proposal. 

[Pascal3] Cool. Please make that another LC issue and the proposed resolution, see if there is anyone adding anything to it.

***********************************************************************************************
[Pascal]
"When an
intermediate router adds itself to a route, it MUST ensure that the
IPv6 address added to the route is reachable in both forward and backward directions."
This is written with the vision that the router has a single interface and acts as a repeater. 
But really a router could have 2 interfaces on a same subnet in which case that clause does not fly.

[Mukul]
All I mean is that the accumulated route MUST NOT have an address that cannot be accessed in one of the directions. If the address cannot be accessed in the backward direction, then the DRO would not be able to travel to the origin.

[Pascal2] Then you're preventing a router with 2 interfaces. That's sad. I'm fine for an experimental draft   but for standard track that will have to be changed.

[Mukul2] OK, I am keeping it the way it is.

[Pascal3] This also need to be logged as a last call issue and its proposed resolution. Nothing wrong with having limitations, yet I think we must have specific text to indicate that the spec so far is limited to devices with a single interface. When we make the Standard Track version, I expect we'll have to go beyond that limitation. The drawback is for experimental  implementations that may not be interoperable with the final solution.

Cheers,
 
Regards,
Mukul

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 2 Apr 2012 18:20:54 -0500 (CDT)

Hi Pascal

[Pascal2] 

[Mukul2]

[Pascal3] 

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

[Pascal]

[Mukul]

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

[Pascal]

[Mukul]

[Mukul2]

[Pascal3] Why do you feel the need to add anything above what RFC 6550 says? I do not see any benefit or additional clarity from doing this.

[Mukul3] RFC 6550 is actually kind of confusing in this regard. On page 9, it says

"A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

This seems to associate the goal with both OF and reachability to certain hosts. Later invocations of the term "goal" seem to refer just to the connectivity aspect, e.g., on page 18 RFC 6550 says

"A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

So, my understanding so far was that the "goal" defines connectivity to a certain hosts. The relation to objective function is not clear at all (if one restricts oneself to reading RFC 6550). The temporary DAGs created in P2P-RPL route discovery provide no connectivity whatsoever to the joining nodes. So, the only reason to set the G flag to 1 would be to allow correct use of an OF. So, I think P2P-RPL spec should use the text I offered above (and repeat below):

"The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created."

What do you think?

[Mukul]

[Mukul3] OK. I will be happy to hear additional opinions.

[Mukul]

[Mukul3] Actually, I would like the next header to be 4 bits and the sequence number to be 4 bits. 4-bit sequence number will still allow up to 16 different messages to be sent during a P2P-RPL discovery. 4 bit next header will allow 16 different possibilities. We can have so many different ways to compress UDP/TCP headers. I think 3 bit next header may not be sufficient.  

[Mukul]

[Mukul3] Could you please explain how does the requirement regarding addresses to be accessible in both forward and backward directions limits P2P-RPL to only single interface devices? I think this requirement means that P2P-RPL cannot be used across link layers. Is that what you mean? I think allowing operation across link layers would require P2P-RDO to accumulate additional information (backward address to be used for forward addresses not accessible in backward direction). I think at the moment we want to avoid this complexity.
*******************************************************************************

Thanks
Mukul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 3 Apr 2012 08:33:22 +0200

HI again Mukul,

[Pascal2] 

[Mukul2]

[Pascal3] 

[Mukul3]

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

[Pascal]

[Mukul]

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

[Pascal]

[Mukul]

[Mukul2]

What do you think?

[Pascal4] If you think this adds value, I will not oppose. Let's keep that as the proposed resolution

[Mukul]

[Pascal4] Fine, let's keep that as the proposed resolution

[Mukul]

[Pascal4] Cool. Let's use that as the proposed resolution

[Mukul]

[Pascal4] Because an IP address is associated to an interface. If you have 2 interfaces, even in a same subnet, there should be 2 addresses.

  We're getting there :)

Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 4 Apr 2012 01:17:47 -0500 (CDT)

Hi Pascal

[Pascal2] 

[Mukul2]

[Pascal3] 

[Mukul3]

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

[Mukul]

[Mukul4] OK. 

[Pascal]

[Mukul]

[Mukul2]

What do you think?

[Mukul4] Sounds good.

[Mukul]

[Mukul4] OK.

[Mukul]

[Mukul4] OK.

[Mukul]

[Mukul4] But, why would the two IP addresses the device has on the same subnet wont be accessible in both forward and backward directions?

Thanks
Mukul