Subject: [Roll] AD review of draft-ietf-roll-routing-metric

From: Adrian Farrel <[email-masked]>
Date: Fri, 26 Nov 2010 08:29:54 +0000

Hi,

I have performed an AD review of your draft.

Don't panic!

I review all drafts that I am responsible for before putting them
forward for IETF last call. The main objective is to catch nits and
minor issues that would show up during the last call or in IESG
review. The intention is to help polish your document and make sure
it is clean and shiny so that other reviewers will stick to the
technical details.

Thanks for an important component of the RPL family.

Most of my comments are pretty trivial, but a couple have more meat
on them and I'd like to see a quick respin of the document before I
issue the IETF last call. As soon as I see a new revision posted,
I'll set the ball in motion.

Of course, all of my issues are up for discussion.

Thanks for the work,
Adrian

---

I am slightly worried about the complexity inherent in this spec.
Although individual implementations and deployments might choose to use
a very limited subset of the available (and flexible) options, it seems
that an implementation must support a much wider subset of options,
metrics, and constraints in order to be deployable into a wide range of
networks.

Does this flexibility impact simplicity of implementation?

---

I think [I-D.ietf-roll-rpl] should be a normative reference.

---

Section 1

   One of the prime objectives of this document is to propose a flexible

s/propose/define/

---

DODAG is used without expansion
On the other hand, DAG is expanded more than once.

---

Section 1

   The best path is the path with the lowest cost with respect to some
   metrics that satisfies all constraints (if any).

Slightly ambiguous. What satisfies the constraints: the path, the cost,
the metrics?

Suggest...

   The best path is the path that satisfies all supplied constraints and
   that has the lowest cost with respect to some specified metrics.

---

Section 1

OLD
   Routing metrics falls into the following sets of characteristics:
NEW
   Routing metrics may be categorized according to the following
   characteristics:
END

(English)

---

Section 1

OLD
   Some link or node characteristics (e.g. link reliability flag,
NEW
   Some link or node characteristics (e.g. link reliability,
END

(the flag is not a characteristic)

---

Section 1

OLD
   remaining energy on the node) may either be used by RPL either as
   routing constraints or metrics.
NEW
   remaining energy on the node) may be used by RPL either as routing
   constraints or as metrics.
OLD

(English)

---

Section 1

OLD
   exclusive (e.g. it is for example possible to advertise a "hop count"
NEW
   exclusive (e.g. it is possible to advertise a "hop count"
END

(English)

---

Section 1

s/dynimicity/dynamicity/

---

Section 1

   It must be noted that the use of dynamic metrics is not new and has
   been experimented in ARPANET 2.  The use of dynamic metrics is not
   trivial and great care must be given to the use of dynamic metrics
   since it may lead to potential routing instabilities.  That being
   said, lots of experience has been gained over the years on the use of
   dynamic routing metrics, which have been deployed in a number of (non
   IP) networks.

Can you add a couple of references? One for ARPANET 2 experimentation,
and one for the "lots of experience gained".

---

Use of RFC 2119 language.

The first use (SHOULD) shows up late in Section 1 after a number of
lower case "must". I think that the best way to smooth this out is to
not use any 2119 language in the Introduction.

---

Section 1

OLD
   nodes in LLN, it is particularly critical to ensure the use of
NEW
   nodes in LLN, it is critical to ensure the use of
END

(critical is a superlative)

---

Please capitalise all section headers

---

Figure 1

This is a copy of figure 22 in draft-ietf-roll-rpl.
I strongly recommend that you do not duplicate protocol bit/byte
definitions as this can lead to accidental discrepancies. Why not
replace this figure with a reference?

---

Bit numberings in fields. Please align the numbers so that we
count bits in base 10.

---

Section 2.1

Routing Metric/Constraint object field descriptions.

Convention is to list these under the figure in the same order as they
appear in the figure. The most disruptive, in this case, is the
dislocation of the P field (which should probably also be called the P
flag).

---

Section 2.1

I think the A flag needs a little more constraint. Not only is it only
valid when C=1 (as stated), but it is only valid when R=0.

Also
OLD
      and MUST be written to 0x00.
NEW
      and MUST be set to 0x00 and MUST be ignored on receipt.
END

---

Section 2.1

   Unrecognized TLVs MUST be ignored.

Do you want to clarify that "ignoring" includes leaving the TLVs in
place in the object when it is forwarded along the DAG?

---

Section 2.2

Have you considered the case that the recording of metrics causes the
Routing Metric/Constraint object to overflow?

---

Section 3.1

   The Node State and Attribute (NSA) object is used to provide
   information on node's characteristics.

s/node's/node/

---

Section 3.1

   The NSA object MAY be present in the DAG Metric Container.  There
   MUST be no more than one NSA object as a constraint per DAG Metric
   Container, and no more than one NSA object as a metric per DAG Metric
   Container.

This is fine, but you will need to define somewhere what happens when
a formatting error is detected. This can either be done on a case-by-
case basis, or can be a general statement in Section 3.

See also, Section 3.2

   The NE object MAY be present in the DAG Metric Container.  There MUST
   be no more than one NE object as a constraint per DAG Metric
   Container, and no more than one NE object as a metric per DAG Metric
   Container.

etc., etc.

Incidentally, it might be more graceful to use "MUST NOT" instead of
"MUST". For example:

OLD
   The HP object MAY be present in the DAG Metric Container.  There MUST
   be no more than one HP object as a constraint per DAG Metric
   Container, and no more than one HP object as a metric per DAG Metric
   Container.
NEW
   The HP object MAY be present in the DAG Metric Container.  There MUST
   NOT be more one HP object as a constraint per DAG Metric Container,
   and there MUST NOT be more than one HP object as a metric per DAG
   Metric Container.
END

---

Section 3.1

There seems to be some duplication of the definition of the O and A
flags.

---

Section 3.1

Is IANA expected to track the flags in the NSA object?

Are the Type values for the TLVs chosen from a common registry across
all objects, or is there a separate registry for each object?

---

Section 3.2

   Whenever possible, a node with low residual energy should not be
   selected as a router

Do you have a reference for this?

---

Section 3.2

   Given the complexity of trying to address such a broad collection of
   constraints, this document defines three levels of fidelity in the
   solution.

I only find two levels defined in the section:
- The simplest solution relies on a 2-bit field
- The mid-complexity solution is a single parameter

Did I miss one, or did you?

---

Section 3.2

   For scavenging nodes, the 8 bit quantity is the power
   provided by the scavenger divided by the power consumed by the
   application, H=P_in/P_out, in units of percent.

and

   For
   battery powered devices, H is the current expected lifetime divided
   by the desired minimum lifetime.

Is the second case also expressed as a percentage?

---

Section 3.2

I'm slightly confused by the difference (or not) between the term 'H'
and the term 'E-E'. Firstly, E-E looks like an arithmetic expression.
But, more to the point, I *think* you put the value of H in the field
E-E, so why have two names for the same thing?

---

Objects, sub-objects, and TLVs

I think you have some inconsistency in naming.

At the top level we have "Routing Metric/Constraint object"
The "object body" of this object is defined as:
   The object body carries one or more sub-objects defined later in this
   document.
So I expect everything that follows in Sections 3 and 4 to be termed
sub-objects. But you have also termed these things as "objects".

Some of the objects/sub-objects in Sections 3 and 4 can, themselves have
sub-objects, while others launch straight into contained TLVs.

This is all a bit confusing (although there is nothing technically
wrong) and it would be really nice to achieve some consistency of
terminology.

---

Section 3.2

   The format of the NE sub-object body is as follows:

And what Type value does this sub-object use?

---

Section 3.2

   o  T (node Type): 2-bit field indicating the node type.  E=0x00
      designates a mains-powered node, E=0x01 a battery-powered node and
      E=0x02 a node powered by an energy scavenger.

Do you mean T=0x00 etc.?

---

Section 3.2

   empty is that I bit is an inclusion.

s/is that/if that/

---

Section 3.2

   Future addenda to this document may include more complex solutions
   involving a half dozen TLV parameters representing energy storage,
   consumption, and generation capabilities of the node, as well as
   desired lifetime.

Can you rephrase this to avoid mentioning "addenda" which we don't
really do? How about:

   Future documents may define more complex solutions involving TLV
   parameters representing energy storage, consumption, and generation
   capabilities of the node, as well as desired lifetime.

---

Section 3.3

   No Flag is currently defined.

Need the usual "set to zero, ignored on receipt" text.

---

Section 3.3

   The HP object may be used as a constraint or a metric.  When used as
   a constraint, the DAG root indicates the maximum number of hops that
   a path may traverse.  When that number is reached, no other node can
   join that path.  When used as a metric, each visited node simply
   increments the Hop Count field.

Are you counting nodes or hops?
Does the first node send the Hop Count as one or zero?

---

Section 3.3

It looks to me that if the object is used as a constraint, it MUST also
be present as a metric. This seems to be different from the burble at
the top of the section. (and obviously, we can think of more optimal
ways of signaling this - such as decrementing the hop count at each
hop).

---

Section 4.1

   For the deeply duty-cycled links
   found in many LLNs

Will this term be clear to the reader?

---

Section 4.1

OLD
   There are several MAC layer
   protocols which allow for the effective bit rate and power
   consumption of a link to vary over more than three orders of
   magnitude, with a corresponding change in power consumption.
NEW
   There are several MAC layer
   protocols which allow for the effective bit rate of a link to vary
   over more than three orders of magnitude with a corresponding change
   in power consumption.
END

---

Section 4.1

With special reference to my comment (above) about objects, sub-objects,
and TLVs, it is really not helpful to have an object (which is actually
a sub-object) and a sub-object of that object both called Throughput!

---

Section 4.1

   Figure 9: Throughput sub-object format

And what Type value does this sub-object use?
But, I might ask why you need sub-objects when the content is well-known
to be 32-bit values, and the parent object has a length field.

---

Section 4.1

   Throughput: 32 bits.  The Throughput is encoded in 32 bits in
   unsigned integer format, expressed in bytes per second.

Are you sure this is enough? Yes, it seems like it today. How future-
proof is this?

---

Section 4.2

   Similarly to throughput, the latency of many LLN MAC sub-layers can
   vary over many orders of magnitude, again with a corresponding change
   in current consumption.

s/current/power/?

---

Section 4.2

Ditto object and sub-object names.
Ditto sub-object Type value.

---

Section 4.2

Again, it looks like the use of this object as a constraint is only
possible if it is also used as a metric. So (again) it looks like the
rules for object presence are broken.

But that depends how it is used as a constraint! It might be used to
mean that no link with unsatisfactory latency may be added to the DAG,
or it might mean that the cumulative latency must not grow beyond the
the constrained limit.

You need to clarify meaning and usage.

---

Section 4.3

   Note that an RPL implementation MAY either use the LQL, the ETX or
   both.

This immediately makes me worry about interoperability.

---

Section 4.3.1

   By contrast, the LQL link metric may be
   aggregated, in which case the sum of all LQLs may be reported
   (additive metric)

How can this possibly be useful? Unless you know how many hops are
traversed, the aggregate is meaningless!

---

Section 4.3.1

     0               1               2               3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
    |       Res     | LQL sub-object
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...

The Res field does not appear to be described.

---

Section 4.3.1

It seems to me that a type 0x02 aggregation is not very helpful because
"unknown" will hide the otherwise 'best' link quality.

But maybe this doesn't matter because 'worst' link quality is more
interesting.

---

Section 4.4.1

Ditto Res field

---

Section 4.4.1

How come the LC field in the two sub-objects have different sizes?

---

Section 4.4.1

   The use of the LC object is outside the scope of this document.

It seems to me you have gone off half cocked :-(

There is some description at the top of the section that implies a
little about how LC is used. It seems closer to a color (a la ToS) than
to a bit array (a la resource affinities).

If you are determined that this is out of scope for your document, I
wonder why the object is defined, and I wonder why the section has
preamble on the use of the meaning of LC. And I really wonder about the
presence of section 4.4.2.

---

Section 6

There doesn't seem to be any tracking of sub-object Type values.

---

Section 7

You really need a reference to draft-ietf-roll-security-framework.

I think that you made a key security comment in a previous section where
you said that it is recommended that the algorithms used do not cause
excess information flapping. A significant security attack might be
mounted by periodically attacking the quality of a link resulting in the
routing protocol flapping. This would cause wider damage than simply
the disruption to the local link.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 26 Nov 2010 16:32:39 +0100

Thanks for the very useful review. Expect a new revision next week !

Thanks.

JP.

On Nov 26, 2010, at 9:29 AM, Adrian Farrel wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll