Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
draft-ietf-roll-routing-metrics-19

[Ballot discuss]
I dislike the complexity and the large number of options that this draft defines. But I have become convinced that they are necessary. I was particularly swayed by the argument that existing proprietary protocols have the same features.

However, I have one remaining concern: given the number of options and different capabilities, I would like to see the draft what options and functionality is mandatory to implement for interoperability.

[Ballot comment]
Based on the reviews provided by IESG members more expert than I in the technology under consideration, I am ballotting "No Objection". That said, based on my own review I concur with the DISCUSS raised by Jari Arkko regarding the complexity of the system.

[Ballot discuss]
This may be a DISCUSS-DISCUSS.

I believe that in order to achieve loop-free routing, the following conditions must be true:

- all nodes must construct identical link state data bases (LSDB)
- all nodes must run identical (or at least equivalent) SPF algorithms over that LSDB

While I understand how ROLL devices might construct identical LSDBs, I don't understand how all nodes will run and identical (or even equivalent) SPF algorithms. The first problem is that all nodes don't neccessarily understand all metrics advertised with C-bit == 0. So, if all SPFs don't understand all of the same inputs, how can they be expected to produce the same outputs? THe second problem is an SPF with multiple inputs is pretty complex. Is it documented well enough that multiple vendors may produce interworking implementations? Finally, a node might advertise a metric with C-bit = 0 and then override that same metric with C-bit =1. When that happens, does the old advertisement disappear from the LSDB.

[Ballot discuss]
I am concerned about the complexity of the RPL system. The set of attributes is relatively complex, 8 different attributes (The BGP parameters registry has 26, but RPL is expected to be run in environments where there is no experts to monitor its operation or fine-tune the parameters.) The large set of attributes, dynamically changing parameters, complex topologies, and unattended operation seems like a recipe for operational and interoperability problems. I do recognize the need to have dynamic metrics, power-aware routing, and many of the other things in this specification, however. My question is whether this is the absolute minimum set that we should define. Do we need Section 2.1 A field? Section 3.1 A or O flags? The mid-complexity solution from Section 3.2? Section 4.3.1 *and* Section 4.3.2 reliability metrics?

A few more specific concerns:

Section 3.1:

  o  A Flag: data Aggregation Attribute.  Data fusion involves more
      complicated processing to improve the accuracy of the output data,
      while data aggregation mostly aims at reducing the amount of data.

This is underspecified. And why do you talk about data fusion, if the
attribute signals data aggregation. Please define what the semantics
of the bit and the participant's behaviour is with respect to data
aggregation, or point to a reference.

[Ballot comment]
I agree with Lars Eggert's Discuss.

Section 4.3:

  In LLNs, link reliability is degraded by external interference and
  multi-path interference (wireless links).  Multipath typically
  affects both directions on the link equally, whereas external
  interference is sometimes unidirectional.

I'm not sure I understand the term "multi-path interference" in this context. Perhaps you should use some other term. Multi-path usually refers to the use of multiple paths simultaneously. Radio interference from multiple links can certainly occur in ROLL networks. But I'm not sure why you call it "multi-path interference". I would probably just say "... degraded by attenuation (due to distance and objects) and interference (from external objects or within the RPL network)".

[Ballot discuss]
Section 3.1:

  o  A Flag: data Aggregation Attribute.  Data fusion involves more
      complicated processing to improve the accuracy of the output data,
      while data aggregation mostly aims at reducing the amount of data.

This is underspecified. And why do you talk about data fusion, if the
attribute signals data aggregation. Please define what the semantics
of the bit and the participant's behaviour is with respect to data
aggregation, or point to a reference.

[Ballot comment]
1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear.

2. Expand DIO at first occurence

3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity.

[Ballot comment]
1. The way the Flag field is defined in Figure 1 is confusing. The field is defined as length 16 bits, but then there are 5 bits labelled Flags on the diagram which are actually the currently reserved or un-allocated Flags. The A field and PRec filed are part of the Flag field, but there is no indication or indent to make this clear.

2. Extend DIO at first occurence

3. Section 4.1 - the Throughput object seems to be mis-named. Looks more like Link Capacity.

[Ballot discuss]
A few issues need to be addressed before I can ballot favorably this document:

1. Section 2.1 - Value: variable for Routing Metric/Constraint TLVs. What is the length range. 255 is maximum I assume, but is zero an acceptable length value?

2. Section 3.1 -

      An implementation MAY
      decide to add optional TLVs (not currently defined) to further
      describe the node traffic aggregator functionality.

It is not clear to me how an implementation can make such a decision. Two different implementations would not be interoperable if this is not defined some place. Is this about extensibility?

3. Section 3.2 - it is not clear from the text that estimating the 'energetic happiness' - actually the remaining power battery for battery operated devices is always possible, and if not how this metrics is being filled in. Will just the E bit be cleared and no estimation provided?

4. Section 4.2 - the latency metric is unsufficiently defined. What is the measurement observation point? is buffering taken into consideration?

5. Section 4.3.1

> The Link Quality Level (LQL) object is used to quantify the link
  reliability using a discrete value, from 0 to 7 where 0 indicates
  that the link quality level is unknown and 1 reports the highest link
  quality level.  The mechanisms and algorithms used to compute the LQL
  are implementation specific and outside of the scope of this
  document.

This seems broken. How can interoperability be ensured between two independent implementations if the metric is a discrete value whose algorithm of determination is implementation specific?

[Ballot comment]
Section 1., paragraph 16:
>    flexibility to use link and node characterisics either as constraints

  Nit: s/characterisics/characteristics/


Section 1., paragraph 21:
>    and unneccessary routing changes.

  Nit: s/unneccessary/unnecessary/


Section 3., paragraph 1:
>    objet MUST silently be ignored.

  Nit: s/objet/object/


Section 4.1., paragraph 0:
> 4.1.  Throughput

  I think you mean (link) capacity here and not throughput. See the
  definition in RFC5136; could you adopt this definition here?


Section 4.2., paragraph 0:
> 4.2.  Latency

  See the definitions in RFC2679, can they be adopted here? Also, is
  this metric supposed to include buffering/queueing delay (which is
  load dependent) or is it purely supposed to capture the link
  transmission delay? If the former, that can vary quite a bit more...


Section 4.3.2., paragraph 12:
>    the path (cummulative path ETX calculated as the sum of the link ETX

  Nit: s/(cummulative/(cumulative/


Section 7., paragraph 1:
>    consist of making intermitment attacks on a link in an attempt to

  Nit: s/intermitment/intermittent/


Section 8., paragraph 1:
>    valuable comments.  Special thank to Adrian Farrel for his thourough

  Nit: s/thourough/thorough/

[Ballot discuss]
DISCUSS: My high-level concern with this document is that it focuses
  on how metrics are encoded in RPL TLVs, rather than giving formal and
  therefore unambiguous definitions of the metrics. Not in all cases,
  but in several. For example, the misnamed "throughput" metric doesn't
  make it clear whether it describes nominal link capacity or residual
  capacity, or whether it is an instantaneous metric or averaged over
  some period, etc. The "delay" metric leaves it open whether buffering
  delays are supposed to be included or not. The link reliability metric
  is much too open; when does e.g. a ZigBee link have a reliability of
  5? When of 6? Hat about a BT-LE link? And so on.

  The reason I'm bringing this up is that in oder to have route selection pick
  paths for end systems based on these metrics, it needs to be understood
  what these metrics concretely *mean*. I don't think that's currently
  possible, and I believe that makes them rather less useful that
  advertised. If IPPM has taught us anything it's that metrics really do
  need to be unambiguously defined for them to be useful.

  I realize this discuss isn't really actionable. I plan to clear it after
  discussing my concern with the IESG call.

[Ballot comment]
In 2.1:

  The A field has no meaning when the C Flag is set (i.e. when the
  Routing Metric/Constraint object refers to a routing constraint) and
  he only valid when the R bit is cleared.  Otherwise, the A field MUST

Is "he" should be here at all?

  be set to 0x00 and MUST be ignored on receipt.

4.1.  Throughput

  Throughput: 32 bits.  The Throughput is encoded in 32 bits in
  unsigned integer format,

In network byte order? (Also in 4.2)

  expressed in bytes per second.

IANA has questions about the IANA Actions requested in this document.

IANA understands that, upon approval of this document, six IANA Actions
need to be completed.

The document requests that a new, top-level registry be created and that
the IANA Protocol Matrix be updated to contain a pointer to this new
registry. The reference in the Matrix and all subregistries will be
[RFC-to-be].

IANA Question --> what should be the name of the newly created registry
that contains the subregistries requested in section 6 of the document?

First, a new subregistry of the new registry created above will be
created. The new subregistry is called "Routing Metric/Constraint Object
Types." New registrations in this subregistry require RFCs. The initial
registrations in this subregistry are:

Value Meaning Reference
1 Node State and Attribute [RFC-to-be]
2 Node Energy [RFC-to-be]
3 Hop Count [RFC-to-be]
4 Link Throughput [RFC-to-be]
5 Link Latency [RFC-to-be]
6 Link Quality Level [RFC-to-be]
7 Link ETX [RFC-to-be]
8 Link Color [RFC-to-be]

IANA Question--> what is the range of values for Routing
Metric/Constraint Object Types? Is value zero undefined, reserved or not
registered?

Second, a new subregistry of the new registry created above will be
created. The new subregistry is called "Routing Metric/Constraint TLVs."
New registrations in this subregistry require RFCs. There are no initial
registrations in this subregistry.

IANA Question--? what is the range of values that will be used for these
TLVs?

Third, a new subregistry of the new registry created above will be
created. The new subregistry is called "Routing Metric/Constraint Common
Headers." New registrations in this subregistry require RFCs. The
initial registrations in this subregistry are:

Codespace of the A field (Routing Metric/Constraint common header)

Value Meaning Reference
0 Routing metric is additive [RFC-to-be]
1 Routing metric reports a maximum [RFC-to-be]
2 Routing metric reports a minimum [RFC-to-be]
3 Routing metric is multiplicative [RFC-to-be]

IANA Question-->what is the range of the common header values?

Fourth, a new subregistry of the new registry created above will be
created. The new subregistry is called "Routing Metric/Constraint Common
Header Flag Field." New registrations in this subregistry require IETF
Consensus. The initial registrations in this subregistry are:

Routing Metric/Constraing Common Header Flag field

Bit Description Reference
12-15 Precedence [RFC-to-be]
9-11 Additive/Max/Min/Multi [RFC-to-be]
8 Recorded/Aggregated [RFC-to-be]
7 Optional Constraint [RFC-to-be]
6 Constraint/Metric [RFC-to-be]
5 P (Partial) [RFC-to-be]

IANA Question-->how should bits 0-4 be marked in this subregistry?

Fifth, a new subregistry of the new registry created above will be
created. The new subregistry is called "NSA Object Flag Field." New
registrations in this subregistry require IETF Consensus. The initial
registrations in this subregistry are:

NSA Object Flag field

Bit Description Reference

14 Aggregator [RFC-to-be]
15 Overloaded [RFC-to-be]

IANA Question --> how should bits 0-13 be marked?

Sixth, a new subregistry of the new registry created above will be
created. The new subregistry is called "Hop Count Object Flags." New
registrations in this subregistry require IETF Consensus. There are no
initial registrations in this subregistry.

IANA Question--> is the bit range for these flags 0 - 15?

IANA understands that these are the only actions required upon approval
of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Routing Metrics used for Path Calculation in Low Power and Lossy Networks) to Proposed Standard


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'Routing Metrics used for Path Calculation in Low Power and Lossy
  Networks'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.

AD Evaluation

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.

Routing Metrics used for Path Calculation in Low Power and Lossy Networks
    draft-ietf-roll-routing-metrics-12

Intended status : Standard Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

David Culler is the document shepherd.
He has personally reviewed the document and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

Yes, the document has had adequate review.  It has gone through several revisions, extensive open discussion, and a full LC process.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

The shepherd has no such concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

Initial versions of this document were incredibly fluffy and full of irrelevant jargon.  Given that the other co-chair was an author, this chair had to ride hard to produce
a credible document of substance.  Some reviewers may have been turned off by those early drafts.  This one is reasonable, so it is important that it be read without prejudice of its history.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

It represents strong consensus of a large group.  There is a camp that view it as unnecessary complexity and also those that view it as essential.  The core RPL spec defines the basics that are sufficient for the former.  This defines the options for the latter.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

Checks have been made. No Known Errors.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

Yes.  References split.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

Yes.

The IANA section of this document includes a detailed list of new
IANA registries.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.                   


  Low power and Lossy Networks (LLNs) have specific routing
  characteristics compared with traditional wired or ad-hoc networks
  that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and
  [RFC5867].  These involve selecting routes that optimize for particular
  metrics under non-trivial constraints. 

  Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have
  used quantitative static link metrics.  Other mechanisms such as
  Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see
  [RFC2702] and [RFC3209]) make use of other link attributes such as
  the available reserved bandwidth (dynamic) or link affinities (most
  of the time static) to compute constrained shortest paths for Traffic
  Engineering Label Switched Paths (TE LSPs).

  This document specifies routing metrics and constraints to be used in
  path calculation by the Routing Protocol for Low Power and Lossy
  Networks (RPL) specified in [I-D.ietf-roll-rpl].  It propose a flexible
  mechanism for the advertisement of routing metrics and constraints
  used by RPL.  Some RPL implementations may elect to adopt an
  extremely simple approach based on the use of a single metric with no
  constraint whereas other implementations may use a larger set of link
  and node routing metrics and constraints.  This specification
  provides a high degree of flexibility and a set of routing metrics
  and constraints, including node state and attributes, node energy,
  hop-count, estimated transmission count, throughput, latency, link
  reliability, mode of operation, or generic 'color'.  Extensions are
  anticipated should ew routing metrics and constraints  be
  defined in the future.

>        Working Group Summary
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

No.  It took several iterations before we had a solid technical document.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

Good.  It is basically defining a type representation, so implementation is trivial.