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

[Mukul Goyal <[e-mail]>]

Hi Pascal,

[Pascal]

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

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

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

[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]
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]
" 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]
I guess not because we still have to accumulate a route (which will be done inside the P2P-RDO).

[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]
This depends on trickle parameters, how you define consistent/inconsistent events. We have made our recommendations in the trickle section of the draft.

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

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

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

[Mukul]
Right! Thanks for catching this.

Thanks
Mukul