Last Call Review of draft-ietf-roll-routing-dispatch-01

Request Review of draft-ietf-roll-routing-dispatch
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-10-25
Requested 2016-10-05
Authors Pascal Thubert, Carsten Bormann, Laurent Toutain, Robert Cragie
Draft last updated 2016-11-03
Completed reviews Genart Last Call review of -01 by Francis Dupont (diff)
Genart Last Call review of -02 by Francis Dupont (diff)
Secdir Last Call review of -01 by Rich Salz (diff)
Intdir Last Call review of -01 by Dave Thaler (diff)
Intdir Last Call review of -01 by Bernie Volz (diff)
Opsdir Last Call review of -01 by Mahesh Jethanandani (diff)
Assignment Reviewer Mahesh Jethanandani 
State Completed
Review review-ietf-roll-routing-dispatch-01-opsdir-lc-jethanandani-2016-11-03
Reviewed rev. 01 (document currently at 05)
Review result Has Issues
Review completed: 2016-11-03


I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-roll-routing-dispatch-01


Ready with issues


I am not a IPv6 expert specially as it relates to 6Lo and while reading the document gave me some idea of what was being suggested, some subtleties were probably lost on me. 


This document defines introduces a new 6LoWPAN dispatch type for use in 6LoWPAN topologies. Using this dispatch type, the specification defines a method to compress RPL Options information and Routing Header type 3.

Management considerations:

The draft clearly outlines management considerations (the first time I have seen one :-)). It states clearly that the solution cannot be deployed in a non-homogenous environment, where there is a mixture of routers that have the compressed and uncompressed headers. 

Most operators are going to find this difficult to deploy, unless it is a green field opportunity. Have the authors considered giving implementors an option of detecting the new header format and letting them decide if they want to provide a solution where these routers can exist in a non-homogenous manner?

Fault management:

The draft talks about what happens when a intermediate router is not able to recognize the new routing header 6LoRH and drops the packet. What is the implication? Does it retry with an alternate path? Do the end points fall back to using the LOWPAN_IPHC? I understand that the draft considers this an administrative error, but unless there is a deterministic way of determining fault (see next section), I can imagine the operators having a very hard time determining why things are not working as expected.

Fault determination:

The document states that if a mismatch is detected, that it is expected the device raises a management alert. But it does not describe what that management alert should be. In the interest of providing consistency, the draft should talk about the alert, what it should be, and how it will be reported. For example, the node that will detect the mismatch is going to be the receiver. Therefore the receiver should report what it was expecting, e.g. compressed header, but it got uncompressed header, or something similar. It will allow an operator to detect not only where the fault is, but what it is.

The document states that it does not require “extraneous code” to exchange and handle error messages for mismatch situations, but does it mean there is error handling code for other situations. Also how are operators are expected to detect a mismatch?

Configuration management:

The draft needs to talk about how individual devices will be configured and monitored for this proposal.

Verifying correct operation:

How is it determined that the device is operating correctly when configured?

A run of idnits revealed one issue that might need to be addressed:


  Checking nits according to


  == It seems as if not all pages are separated by form feeds - found 33 form

     feeds but 37 pages

 Checking references for intended status: Proposed Standard


     (See RFCs 3967 and 4897 for information about using normative references

     to lower-maturity documents in RFCs)

  == Missing Reference: 'RFCthis' is mentioned on line 1170, but not defined

  == Outdated reference: A later version (-05) exists of


  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154'

  == Outdated reference: A later version (-09) exists of



Mahesh Jethanandani

mjethanandani at