Skip to main content

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

Discuss


Yes

(Adrian Farrel)

No Objection

(Barry Leiba)
(Benoît Claise)
(Gonzalo Camarillo)
(Pete Resnick)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)
(Wesley Eddy)

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

Ralph Droms Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (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)?
Adrian Farrel Former IESG member
Yes
Yes (for -15)

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-02-03 for -16)

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -16)

                            
Brian Haberman Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2013-03-21)
Thanks for addressing my concerns.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -16)

                            
Martin Stiemerling Former IESG member
(was Discuss) No Objection
No Objection (2013-03-22)
Thank you for addressing my concerns!
Pete Resnick Former IESG member
No Objection
No Objection (for -16)

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -16)

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -16)

                            
Russ Housley Former IESG member
No Objection
No Objection (2013-02-04 for -16)
  As already pointed out in the Gen-ART Review by  Alexey Melnikov,
  please expand the First use of "DIO".
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2013-03-27)
Thank you for dealing with my discusses.
Stephen Farrell Former IESG member
No Objection
No Objection (2013-02-07 for -16)
(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.)
Stewart Bryant Former IESG member
No Objection
No Objection (for -16)

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -16)