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

["Pascal Thubert (pthubert)" <[e-mail]>]

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