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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Mar 2012 12:23:34 +0200

Dear authors:

The draft is really clear and readable. Thanks a lot for this excellent
work.

General
----------
I understand the need for concise messaging, which tends to create
specific options with one stop shopping for all needed information in
there.
OTOH RPL has a modular use of options that enable multiple sorts of
combinations and factorization. Using Target option is a good move.

Main suggestions:

1) Remove the target from the new P2P route discovery option. So you can
place one or more times a P2P RD Option each followed by one or more
target option(s), or set different lookup parameters for different
targets.
2) Allow for targets that are not necessarily unicast.
3) Allow for (compressed) UDP header in the data. The completely opaque
forms limits the use of the option a bit too drastically.

/* In another draft I'd think we need to allow a mode with target but
not P2P RD option. This would be done to trigger DAOs, e.g. to complete
a hole in a Source Route recursion, or save space in storing mode. */

Detailed review

"Forward Route: A route in the forward direction, i.e., from the
origin to the target."
I think you want to define the forward direction first and then the
forward route. In both case you probably want to capitalize all
instances in the text. Same goes for the following terms.

"By not allowing the generation of DRO messages,
an origin can use P2P-RPL as purely a mechanism to deliver timecritical
application data to the target(s)."

If DRO establishes path from origin to target then without a DRO, the
target can send to the origin, not the other way around?
If so I'd reword like if DRO is not requested, the DAG can only be used
unidirectionally to report data from the target(s) to the origin.

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

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

" A P2P mode DIO:
o MUST carry one (and only one) P2P Route Discovery Option
(described in Section 7.1). The P2P Route Discovery Option allows
for the specification of one unicast or multicast address for the
target."

Well; I can see how there would be only a target and no RDO, if we have
good defaults.
And I can see how a target could have a different DRO than the next
target in the same DIO.
So I do not agree with that statement at all.

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

" When a target receives a P2P mode DIO, it forwards the data in any
Data Options to the higher layer."
As I hinted, this is not well enough defined. You're really using the
DIO as a transport, so you need a minimum transport paradigm like a
compressed UDP header.
This comment applies to DRO as well, obviously.

" Options: The DRO message:
* MUST carry one P2P-RDO that MUST specify a complete route
between the target and the origin;"
If we establish a hop by hop with default values, could we live with
just a target?

/*I did not review the trickle piece considering that Phil went through
it and was satisfied */

9.4: I'ma bit confused about the node that received multiple DIOs. 
Like: Should a node wait a bit before issuing its own DIO, to
accommodate for a better route being received later? 
Can the data option be different from one DIO to the next? 

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

" A target MUST NOT forward a P2P mode DIO any further." 
That is, if it is the only target in the DIO, AND the target is unicast.

Cheers!

Pascal

Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 29 Mar 2012 12:03:15 -0500 (CDT)

Hi Pascal

Thanks for your detailed comments!

[Pascal]
General
----------

[Mukul]
I understand your desire for modular design. But I think the need to save bytes is equally compelling. Specifying the (first) target inside the P2P-RDO allows byte savings in two ways:
1) 4 bytes saved by not specifying type, length, flags and prefix length fields of the target option
2) additional bytes saved by eliding the well known prefix part of the target address. 

By including the target address in the P2P-RDO, we have optimized for the common case. The RPL target option does come into picture when more than one target addresses need to be specified. 

[Pascal] 
Main suggestions:

[Mukul]
My feeling is that allowing multiple P2P-RDOs inside a P2P mode DIO is not a good idea because:
1) P2P-RDO specifies general parameters of route discovery: whether we want hop-by-hop route or source routes; if source route than how many; what is the life time of the temporary DAG; what is the max rank allowed inside the temporary DAG. We do allow discovery of routes to multiple targets with one invocation of P2P-RPL mechanism, but it seems that the general parameters of route discovery would not vary across targets.
2)P2P-RDO accumulates a route. We obviously dont want multiple copies of the accumulated route inside a DIO. Also, if we were to accumulate route in one P2P-RDO but not in others, that sounds complicated too.

[Pascal]

[Mukul]
We do allow that already! The target address could be unicast or multicast.

[Pascal]

[Mukul]
I understand your logic and I am receptive to this idea. Let me get back to you on this. My objective was to keep things flexible. But looks like the common case is that the Data option would have UDP header+payload.

[Pascal]

[Mukul]
That sounds like a good idea.

[Pascal]
Detailed review

[Mukul]
Sounds good.

I will address your remaining comments in the next message.

Thanks
Mukul

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 30 Mar 2012 00:52:59 -0500 (CDT)

Hi Pascal,

[Pascal]

[Mukul]
What I meant was that an origin could use P2P mode DIOs to send time critical data to the target(s) without discovering routes to these targets. Note that the temporary DAG itself cant be used for routing. The target ofcourse would know of a source route back to the origin when it receives a P2P mode DIO.

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

[Pascal]

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

[Pascal]
" A P2P mode DIO:

[Mukul]
Sure, the RPL target option could be used in the manner you described earlier. I don't think a P2P-RPL route discovery can take place without a P2P-RDO. You need P2P-RDO to accumulate the route even if you somehow already knew what kind of route you want to discover etc.

[Pascal]  

[Mukul]
It is certainly possible that you want to discover a source route to one target and a hop-by-hop route to another. But, it seems to me that such flexibility might not be very useful in practice. The common case seems to be that same type of routes need to be discovered for all the targets. Plus, if there are multiple P2P-RDOs in a P2P mode DIO, I will have to create a separate option to do the route accumulation (because I dont want to replicate the accumulated route in all the P2P-RDOs in the DIO). I guess you would like that approach better since it is more modular. But, as I mentioned earlier, home/building world applications have a deep desire to save bytes whereever possible and extra options mean extra overhead in terms of bytes.
  
[Pascal]

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

[Pascal]

[Mukul]
I am working on this. We could impart more structure to the data option. My fear is that if that particular structure (say a particular way to compress the UDP header) is not convenient to use in a particular deployment, the data option itself becomes useless. Would it be preferable if we simply suggest that the data in the data option be transport layer header+payload without actually enforcing a particular structure? What do you think? 

[Pascal]

[Mukul]
I guess not because we still have to accumulate a route (which will be done inside the P2P-RDO).

[Pascal]

[Mukul]
This depends on trickle parameters, how you define consistent/inconsistent events. We have made our recommendations in the trickle section of the draft.

[Pascal] 

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

[Pascal]
"When an

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

[Pascal]

[Mukul]
Right! Thanks for catching this.

Thanks
Mukul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 30 Mar 2012 11:06:32 +0200

"By not allowing the generation of DRO messages, an origin can use P2P-RPL as purely a mechanism to deliver timecritical application data to the target(s)."

If DRO establishes path from origin to target then without a DRO, the target can send to the origin, not the other way around?
If so I'd reword like if DRO is not requested, the DAG can only be used unidirectionally to report data from the target(s) to the origin.

[Mukul]

[Pascal2] Makes sense. I think you need to articulate the 2 possible use cases. 
1) If you just want to post one datagram to the target(s), what happens, what's the minimum set of information in the DIO? E.g. If no response is expected, you do not need to record a route. 
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.

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

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

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

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

[Pascal]" A P2P mode DIO:
o MUST carry one (and only one) P2P Route Discovery Option (described in Section 7.1). The P2P Route Discovery Option allows for the specification of one unicast or multicast address for the target."

Well; I can see how there would be only a target and no RDO, if we have good defaults.

[Mukul]

[Pascal2] I can see why most of the time in the usage you have in mind the RDO will be there. Need => use is fine with me. But MUSTing the use has the logic backwards and again you are limiting the applicability of your draft.
e.g. I read above that you might use DIO to deliver critical data to the target. I have not read that this always implies an ack back. So why store the route?

[Pascal]
And I can see how a target could have a different DRO than the next target in the same DIO.
So I do not agree with that statement at all.

[Mukul]
  
[Pascal2] BTW typo up there, I meant RDO. It's (slightly too) easy to mix those 2 up... And I understand you have to find a trade-off. You have to package together things that have a strong logical relationship. And split things that can be used separately as much as you can afford within practical constraints... Not an easy task. When I look at the RDO, my preferred split is to take the target out and keep the rest in. I have a doubt with regards to the lifetime field though; maybe we could actually move it to the reserved field into the DIO base object. I can see how the usage can be generalized to non P2P yet transient DAGs. That would give you more granularityfro both lifetime and maxrank. 

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

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

[Pascal]
" When a target receives a P2P mode DIO, it forwards the data in any Data Options to the higher layer."
As I hinted, this is not well enough defined. You're really using the DIO as a transport, so you need a minimum transport paradigm like a compressed UDP header.
This comment applies to DRO as well, obviously.

[Mukul]

[Pascal2] You need to specify at least one field to indicate the "next header". Maybe you could look at how RFC 6282 does it for UDP?  As an alternate to UDP, you could define a 'well known, free form'  NH for a device that has only one possible consumer for the data.

[Pascal]
" Options: The DRO message:
* MUST carry one P2P-RDO that MUST specify a complete route between the target and the origin;"
If we establish a hop by hop with default values, could we live with just a target?

[Mukul]

[Pascal2] Ooups OK 

[Pascal]
/*I did not review the trickle piece considering that Phil went through it and was satisfied */

9.4: I'ma bit confused about the node that received multiple DIOs. 
Like: Should a node wait a bit before issuing its own DIO, to accommodate for a better route being received later?

[Mukul]

[Pascal2] Ooups OK

[Pascal]

[Mukul]

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

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

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

[Pascal]

[Mukul]

[] Cheers;

Pascal

---

From: Mukul Goyal <[email-masked]>
Date: Sat, 31 Mar 2012 18:41:19 -0500 (CDT)

Hi Pascal

Separating each point with "********".
Also, I have removed points where you did not have further comments.

*******************************************************************
[Pascal]

[Mukul]

[Mukul2]
I will add text to the effect that address accumulation need not take place if the Reply flag is zero. I think every thing else stays same.

[Pascal2] 

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

[Pascal]

[Mukul]

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

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

[Pascal]

[Mukul]

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

**************************************************************************
[Pascal]" A P2P mode DIO:
o MUST carry one (and only one) P2P Route Discovery Option (described in Section 7.1). The P2P Route Discovery Option allows for the specification of one unicast or multicast address for the target."

[Mukul]

[Mukul2] Indeed the route accumulation is not required when the P2P mode DIO is simply carrying data with no route discovery intended. In that case, the R flag in the P2P-RDO would tell nodes not to do route accumulation. We would still be forming a temporary DAG, hence we need the L field inside the P2P-RDO to tell the nodes about the life time of the temporary DAG. The Compr field would still be useful to elide some bytes from the target address and the MaxRank field could still be used to constrain the temporary DAG. So, P2P-RDO is useful in the particular scenario where P2P-RPL is being used as a pure data delivery mechanism.

P2P-RPL is primarily a reactive route discovery protocol that uses trickle-controlled propagation of discovery messages by creating a temporary DAG. By its very nature, its hard for me to imagine P2P-RPL invocation where a P2P mode DIO does not need to carry a P2P-RDO. The kind of flexibility you have in mind is more suitable for the underlying mechanisms - the trickle algorithm and the concept of DAG creation/maintenance. Just my views.

************************************************************************     
[Pascal]
And I can see how a target could have a different DRO than the next target in the same DIO.
So I do not agree with that statement at all.

[Mukul]
  
[Pascal2] BTW typo up there, I meant RDO. It's (slightly too) easy to mix those 2 up...

[Mukul2] I know! My co-authors mix up RDO-DRO all the time. But, I would still like to name them the way they are named.:)

[Pascal2]
 And I understand you have to find a trade-off. You have to package together things that have a strong logical relationship. And split things that can be used separately as much as you can afford within practical constraints... Not an easy task. When I look at the RDO, my preferred split is to take the target out and keep the rest in. I have a doubt with regards to the lifetime field though; maybe we could actually move it to the reserved field into the DIO base object. I can see how the usage can be generalized to non P2P yet transient DAGs. That would give you more granularityfro both lifetime and maxrank. 

[Mukul2]: At the moment, P2P-RPL is the only RPL extension that needs transient DAGs. I guess moving the lifetime to DIO base object would make sense when additional applications/extensions emerge that would benefit from such a move. When that happens, we could define a new version of P2P-RDO.
  
****************************************************************************************

[Mukul]

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

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

[Pascal]

[Mukul]

[Mukul2] I like the proposal you make next (3 bits of next header and 5 bits of sequence).

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

[Mukul]

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

***********************************************************************************************
[Pascal]
"When an

[Mukul]

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

Regards,
Mukul