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

[Mukul Goyal <[e-mail]>]

Hi Pascal

Thanks for your detailed comments!

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

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

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.

[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]
2) Allow for targets that are not necessarily unicast.

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

[Pascal]
3) Allow for (compressed) UDP header in the data. The completely opaque
forms limits the use of the option a bit too drastically.

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

[Mukul]
That sounds like a good idea.

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

[Mukul]
Sounds good.

I will address your remaining comments in the next message.

Thanks
Mukul