Document: draft-ietf-roll-rpl-11 Reviewer: Brian Carpenter Review Date: 2010-09-20 IESG Telechat date: 23 Sept 2010 Summary: New I-D needed -------- I'm happy with the authors' proposed changes in response to my Last Call review, but a -12 version is definitely needed. A couple of my issues were classed as major, copied below with the key part of the responses. For full details see http://www.ietf.org/mail-archive/web/gen-art/current/msg05613.html > Major issues: > > ------------- > > >> > > 3.3.7. Datapath Validation and Loop Detection >> > > >> > > RPL carries routing information in a RPL Option contained in an IPv6 >> > > Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-option]. > > > > I'm aware that this choice was a major discussion point and that using > > the IPv6 Flow Label to support RPL was rejected for very sound reasons. > > However, I can't help worrying about the impact of this overhead > > on packet size and processing load in the ROLL context. More generally, > > RPL is complicated, and that means memory, processing, and bits on > > the wire. This whole approach seems to call for a rationale, either > > as an Appendix to this document, or as a separate Informational document. > > I don't see any trace of this in the WG charter pages. We'll produce a small additional text and provide further informative references to give some background for the rationale in the art and practice. In short, what RPL applies is a rather common/best practice in this space to ignore a transient routing inconsistency (at worst a loop) unless there's traffic that actually suffers from it. >> > > 3.3.8. Distributed Algorithm Operation > > ... >> > > It is up >> > > to the end-to-end application to select the RPL instance to be >> > > associated to its traffic (should there be more than one instance) >> > > and thus the default route upwards when no longer-match exists. > > > > This worries me quite a bit. We have a long history of not expecting > > applications to know anything about routing, and now we expect them > > to select a routing instance? How is that going to happen? Will there > > be a default choice of RPL instance? > > We don't mean to suggest that applications must know about routing, and in fact we don't mean to mandate anything about how a mapping to a RPL instance may or may not occur. To clarify the text, we propose to relax any text such as the excerpt you have pointed out where it can be construed that the application endpoint itself must be aware of the RPLInstanceID.