Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
draft-ietf-roll-p2p-rpl-17
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)
Unknown
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)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-02-03 for -16)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -16)
Unknown
Brian Haberman Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2013-03-21)
Unknown
Thanks for addressing my concerns.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -16)
Unknown
Martin Stiemerling Former IESG member
(was Discuss)
No Objection
No Objection
(2013-03-22)
Unknown
Thank you for addressing my concerns!
Pete Resnick Former IESG member
No Objection
No Objection
(for -16)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -16)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -16)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2013-02-04 for -16)
Unknown
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)
Unknown
Thank you for dealing with my discusses.
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-02-07 for -16)
Unknown
(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)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -16)
Unknown