[Roll] AD review of draft-ietf-roll-p2p-measurement-06

["Adrian Farrel" <[e-mail]>]

Hi,

I have done my usual AD review of your document as part of processing
the publication request. This review should be considered alongside 
my review of draft-ietf-roll-p2p-rpl as the documents are closely 
linked.

I have a number of questions and minor issues that I would like to
resolve before advancing the documents. 

As usual, all of my comments are up for discussion, but I think that a
new revision will be needed, so I have moved the document into "Revised
I-D Needed" state in the data tracker and will wait for your emails 
and/or a new revision.

Many thanks for your work,
Adrian


---

As with draft-ietf-roll-p2p-rpl, I would like some discussion in the
Introduction about why this Experimental and what you expect to
discover. I think the text is easier for this document...

   This document provides a mechanism that can be used to determine
   whether and how to establish a new point-to-point route in an LLN.
   This utility of the mechanism described in this document is, 
   therefore, dependent on the existence of a protocol mechanism for
   establishing P2P routes. [I-D.ietf-roll-p2p-rpl] is targeted at
   publication as an Experimental RFC for reasons described in that
   document. It makes sense, therefore, for this document also to be
   targeted as Experimental.

   As experience is gained using the mechanisms described in
   [I-D.ietf-roll-p2p-rpl] it is hoped that the mechanisms described in
   this document will also be used, and feedback will be provided to the
   ROLL working group on the utility and benefits of this document.

---

I think that "quality" is the wrong word. "Quality" is usually
associated with measures like packet loss, delay, and jitter. I don't
think you are measuring those things, and while I understand why you
say "quality of a route", I think you need some other phrase.

I think this more like...

  A Mechanism to Record the end-to-end Metrics of a Point-to-point
             Route in a Low Power and Lossy Network

In the Introduction, you have some nice words...

   to measure
   the aggregated values of the routing metrics along the existing
   route

---

Abstract

I'm confused :-)

The document title is very specific to P2P routes. But the Abstract 
(deliberately?) does not mention P2P. Section 1 seems to imply that I
could run the mechanisms on any route from origin to target to see if it
is good enough - and that would include routes created using normal RPL.
But section 2 explicitly constrains the mechanism to P2P routes.

Furthermore, the redefined terminology in 1.1 (see below for my 
objection to that!) seem to suggest measuring from an arbitrary origin
to an arbitrary target regardless of whether a P2P route exists.

Can you:
- unconfuse me
- make sure that the abstract and introduction explain the real
  situation
- make sure the document title is accurate
- make sure that the document is consistent
- be careful with terminology (just because you run the mechanism from
  A to B in a point-to-point sort of way, doesn't mean that there is a
  P2P route from A to B)

---

1.1                    

Did you really need to redefine these terms instead of use new terms for
new concepts? Given how close the two documents are, it's a shame to 
confuse things.

---

3.1

I was going to say...

   Seems like the H flag is not needed since leaving it clear is 
   semantically equivalent to setting RPLInstanceID=0b10000000

   Not very important, but you increase the chances of a malformed 
   message, and you use your last bit that could be reserved for 
   future use.

...but then I read the text lower down about how a transit router
can change the H flag under special circumstances. Now I am confused
because if the H flag setting is changed, surely the rule governing 
the RPLInstanceID is broken.

---

3.1

Some of the flag settings that have no meaning dependent on other
flag settings are described as "MUST be set to zero" which is fine.
But should you also say they should be ignored?

---

3.1

I found the description of what goes in the Metric Container Options
inadequate. There should at least be a forward pointer to some section
that describes how this piece of the MO object is constructed, but some 
text would help as well.

---

Section 4

   The Origin MUST discard the MO message if:

That reads a bit odd. Didn't the Origin just build the message? Why 
would it build a message and then discard it? Why not just not build a
bad message?

---

Section 5

   An Intermediate Router MUST discard the packet with no further
   processing if the received MO is not a Measurement Request.

For clarity and consistency with other paragraphs, can you add...

   i.e., if the T flag is not set to one.

---

Section 7

   The Origin MUST discard the packet with no further processing ...
   ... if the Origin has no
   recollection of sending a Measurement Request with the sequence
   number listed in the received MO.

Trying to decide why that is a "MUST".
I guess there are some security/bug considerations.
But are you unduly limiting the Origin implementation to be required to
keep track of the MOs that it sends?

---

Section 7

   The Origin MUST examine the routing metric objects inside the Metric
   Container options to evaluate the quality of the measured P2P route.
   If a routing metric object contains local metric values recorded by
   routers on the route, the Origin MUST aggregate these local values
   into an end-to-end value as per the aggregation rules for the metric.

That is going too far in the use of "MUST". The Origin can do anything 
it likes with the Measurement Reply including discard it, hash it and
use it as a random number, or process it according to policy! I think
what you need is...

   The Origin can use the routing metric objects inside the Metric
   Container to evaluate the metrics for the measured P2P route. If a
   routing metric object contains local metric values recorded by 
   routers on the route, the Origin can make use of these local values
   by aggregating them into an end-to-end metric according to the 
   aggregation rules for the specific metric. An Origin is then free to 
   interpret the metrics for the route according to its local policy.

---

Section 8

Question. Can I use this mechanism to find out stuff about the network
that should/would otherwise be private? And could I, as an outside node
do that?

For example, if I sit next to the network and ping every possible P2P 
route, can I find out which nodes are almost out of battery, and which
nodes are key nodes in the topology? Knowing this would help me attack
the network. What are the protections?


---

11.2
You have used [I-D.ietf-roll-p2p-rpl] as a normative reference (at 
least for the terminology).