Last Call Review of draft-ietf-roll-routing-dispatch-01
review-ietf-roll-routing-dispatch-01-opsdir-lc-jethanandani-2016-11-03-00

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

Status:

Ready with issues

Disclaimer:

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.

Summary:

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

http://www.ietf.org/id-info/1id-guidelines.txt:

  ----------------------------------------------------------------------------

  == 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

     draft-ietf-6lo-paging-dispatch-04

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

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

     draft-ietf-roll-useofrplinfo-08

Thanks.

Mahesh Jethanandani

mjethanandani at gmail.com