Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
RFC 6997

Note: This ballot was opened for revision 15 and is now closed.

(Ralph Droms) Discuss

Discuss (2013-02-06 for -16)
I have several architectural issues with the protocol specified in
draft-ietf-roll-p2p-rpl that I would like to discuss.

1. The Data Option introduces a new style of datagram delivery,
roughly based on IPv6, but with different delivery semantics.  The
Data Option also appears to be underspecified; for example:

* How is the checksum in the "upper layer protocol header ... in the
  Data field ..." computed; what is the pseudo-header?
* Does it make sense to carry, e.g., TCP in a P2P-RPL message that
  might be delivered to multiple targets?

I'm especially concerned by:

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

which seems to allow P2P-RPL to operate solely as a Internet-layer
delivery mechanism without generating any routing information.

I had a brief discussion with Adrian about the Data Option. In my
opinion, the Data Option needs a more careful review, for example by
the 6man working group (someone in Transport, as well?), before it can
be published.  Adrian made the suggestion to remove the Data Option
from this document and publish it as a separate draft, which would
avoid delaying this document and allow for additional refinement of
the Data Option specification.

2. The use of the PIO option in P2P-RPL needs to be reviewed by 6man.
In my opinion, the PIO option should not be used here.  We already
have ND and RPL for disseminating information about prefixes.

3. Does it matter which of its addresses an intermediate node inserts
in the address list in the P2P-RDO?  If it does - and I expect it
might make a difference if, for example, the node has multiple non-LL
addresses from multiple RPL instances or the node has multiple
interfaces - how does the node know which address to select?  Are LL
addresses OK?

4. How does a node process and forward P2P-RPL control messages if it
has multiple interfaces?  For example, does it forward those messages
on all interfaces, including the one on which the control message was
received (as it would if the node has one interface)?
Comment (2013-02-06 for -16)
No email
send info
1. selection of routes by the Target and sending the DRO:

In the Hop-by-Hop case, after the route is selected and DRO is sent,
can the Target send a better route to override the route sent earlier?
I'm thinking of the case in which an optimization occurs while the
temporary DODAG is running and the Target gets a better route.  Or,
once it has sent a DRO, does it resend the same route after receipt
subsequent DIOs?

In the Source-route case, does the Target send N DROs, one with each
selected route, and then stop sending DROs?

2. In section 9.7: Why is the DRO multicast to the next hop on the
path to the Origin?  Isn't the address of the next hop in the DRO
address list?

3. Does RPL have the same behavior that routes installed by RPL may
be retained beyond the lifetime of the DAG that caused the routes to
be installed?  If not, it might be helpful to add a note giving
implementors a heads-up.

4. Related to earlier comments about address selection, in section
9.4, this text:

   if the router cannot elide Compr (as specified in
   the P2P-RDO) prefix octets from its IPv6 address

ought to be edited to reflect that the Intermediate Router may have
multiple IPv6 addresses to choose from.  Should the Intermediate
Router consider the Target prefix and Compr in the selection of an
address to add to the P2P-RDO?

5. What link-scoped multicast address is used for forwarding
DROs?

The following are simply editorial nits:

1. It would be clearer (for me, anyway!) if the mode were simply given
as "Hop-by-Hop mode" or "Source routing mode" rather than by "H flag
is zero".

2. In section 11, "An Origin MAY use a Source Routing Header (SRH)
[RFC6554]...".  What else would it use?  How about "An Origin uses the
Source Routing Header (SRH) [RFC6554]..."

3. section 9.3: "send or receive" -> "send or process" (it's hard to
not receive the messages)

4. This sentence might benefit from more detail: "The temporary DAG
MUST NOT be used to route packets" (unless using a DAG to route data
packets [which is what I think is implied] is a term of art).

5. For consistency, could the DRO be named P2P-DRO?

(Adrian Farrel) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2013-02-07 for -16)
No email
send info
(Apologies, I had to read this document in chunks due
to other time pressures, so this review might also be a
bit chunky;-)

- I agree with Sean's DISCUSS

- section 3, the term Target might create an irritating
conflict with how that same term is used in geopriv but
I'm guessing you won't want to change.

- section 4, I don't quite get how this is triggered,
in the remote-conrol/lamp case, is the remote-control
the Origin or a non-router host? If the latter, then
I'm not sure how the remote-control's next-hop router
could know to trigger this process. The former option
seems quite constraining, since it'd mean that all
hosts that can benefit from this need to be p2p-rpl
aware routers, and that seems less rather than more
likely.

- section 4, I'm also not sure how the remote-control
knows the lamp's IP address to start with. How's that
work?  Specification for that probably doesn't belong
here, but I wondered and it might be good to explain a
bit in this draft.

- section 4, 3rd last para: I don't see how the guy who
makes the remote-control (if its the Source LLN router)
can know how to set all those things that the "network
designer" knows how to set. Maybe I'm just missing the
point?

- section 5: sending application data with routing
messages seems to have security issues since the DIOs
are sent more or less all over I think? That implies
that a one-to-many confidentiality service might be
needed which seems very very hard (i.e. silly) in a p2p
context. And of course that also assumes that the
application runs on the "Source" LLN router as well so
you can know what is and is not time-critical. I also
wonder what'd happen if the "application data" you mean
were a TCP SYN packet which seems likely isn't it? The
same security issues arise with the data option in a
DRO. (FYI in case it helps this would have generated a
DISCUSS from me for a standards track protocol but
since there are already two discusses about this I'll
not pile on.)

- 6.1, Why is "Authentication Enabled: 0" the default
and why does that differ from 6550? (If it does.)

- 7.1, Lifetime field - it wasn't clear to me when a
router starts counting down to the end of the Lifetime
for the DAG. 

- 7.2, Only allowing 256 bytes here may effectively
mean securing that data is never possible. That seems
undesirable.

- 7.2 saying a deployment SHOULD take security into
consideration seems meaningless.

- section 8 says the DODAGID identifies the Origin and
that confused me, do you mean its value is the origin's
IP address?

- section 13 says: "Each RPL control message has a
secure version that allows the specification of the
level of security and the algorithms used to secure the
message. " and " These DIOs can be used in their secure
versions if desired" but I have to say I'm unconvinced
that that's sufficiently well defined here (or in 6550)
to allow interop and offer useful security. There
doesn't seem to be any mention of the "secure DRO" in
section 11 for example. I'd love to be proven wrong
however, so can you try convince me that I'm wrong?
(This would also have been a DISCUSS on a standards
track document, even if the authors could justifiably
say that the real fault lies in 6550.)

(Brian Haberman) (was Discuss, No Objection) No Objection

Comment (2013-03-21)
No email
send info
Thanks for addressing my concerns.

(Russ Housley) No Objection

Comment (2013-02-04 for -16)
No email
send info
  As already pointed out in the Gen-ART Review by  Alexey Melnikov,
  please expand the First use of "DIO".

Barry Leiba No Objection

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2013-03-22)
No email
send info
Thank you for addressing my concerns!

(Sean Turner) (was Discuss) No Objection

Comment (2013-03-27)
No email
send info
Thank you for dealing with my discusses.