Skip to main content

The Minimum Rank with Hysteresis Objective Function
RFC 6719

Revision differences

Document history

Date Rev. By Action
2016-12-07
11 (System) Received changes through RFC Editor sync (added Errata tag)
2016-11-30
11 (System) Closed request for Last Call review by TSVDIR with state 'Unknown'
2015-10-14
11 (System) Notify list changed from roll-chairs@ietf.org, draft-ietf-roll-minrank-hysteresis-of@ietf.org to (None)
2012-09-11
11 (System) RFC published
2012-08-16
11 Michael Richardson Changed shepherd to JP Vasseur
2012-07-17
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2012-07-17
11 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2012-07-17
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2012-07-16
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2012-07-16
11 (System) IANA Action state changed to In Progress
2012-07-16
11 Cindy Morgan State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2012-07-16
11 Cindy Morgan IESG has approved the document
2012-07-16
11 Cindy Morgan Closed "Approve" ballot
2012-07-16
11 Cindy Morgan Ballot approval text was generated
2012-07-14
11 Adrian Farrel Ballot approval text was changed
2012-07-14
11 Adrian Farrel Ballot approval text was generated
2012-07-14
11 Adrian Farrel Ballot writeup was changed
2012-07-07
11 Ralph Droms
[Ballot comment]
Thank you for addressing my Discuss points in the most recent
rev of this document.  I've cleared my Discuss.

While these comments are …
[Ballot comment]
Thank you for addressing my Discuss points in the most recent
rev of this document.  I've cleared my Discuss.

While these comments are non-blocking, they should be considered
carefully as they are based on implementation experience with this
draft.

1. The second component of the path cost in section 3.1:

  2.  The value of the selected metric in the metric container in the
      DIO sent by that neighbor.

is incompletely described.  While an implementor should realize from
section 3.5 that the rank advertised by the neighbor is an
approximation for ETX and should be used here, the text as written is
incomplete.

2. Also for completeness, the document should specify the
representation used for ETX to be used in path cost computation; e.g.,
as specified for the ETX sub-object in RFC 6551.

3. Related to point 2, explanation of the relationship between the
representation used for ETX and rank should be explained, especially
considering what I think will be unexpected side effects of the value
of DEFAULT_MIN_HOP_RANK_INCREASE defined to be 256 in RFC 6550
interacting with the (presumed) default representation of ETX as
defines in RFC 6551.

4.  In section 3.4:

  If ETX is the selected metric, a node SHOULD NOT advertise it in a
  metric container.

s/SHOULD NOT/MUST NOT/ (and this text is redundant relative to the
last sentence of section 3.5).

5. Are the parameter values in section 5 recommended only for use when
the selected metric is ETX; seems to me MAX_LINK_METRIC, MAX_PATH_COST
and PARENT_SWITCH_THRESHOLD depend on the selected metric and the
recommended values wouldn't make much sense for, e.g., hop count.

These comments are purely editorial and offered to improve the clarity
of the document.

1. The paragraph immediately following table seems superfluous.  The
list of metrics for which the rank is undefined is not complete (from
RFC 6551).  The paragraph begs the question "why would the deployment
choose a metric for which the rank is undefined?"

2. Readability would be improved by writing the details of the
special-case treatment of ETX (currently in section 3.5) to the point
at which that special-case treatment modifies other behavior specified
in the document; e.g., the second component of the path cost cited
above.

3. The second sentence of section 6 is pretty opaque.  Is the point
that the "List of supported metrics" from section 18.2.3 need not be
supported if MRHOF is used?

4. Isn't the last paragraph of section 6.1 true for any selected metric?
2012-07-07
11 Ralph Droms Ballot comment text updated for Ralph Droms
2012-07-07
11 Ralph Droms
[Ballot comment]

While these comments are non-blocking, they should be considered
carefully as they are based on implementation experience with this
draft.

1. The second …
[Ballot comment]

While these comments are non-blocking, they should be considered
carefully as they are based on implementation experience with this
draft.

1. The second component of the path cost in section 3.1:

  2.  The value of the selected metric in the metric container in the
      DIO sent by that neighbor.

is incompletely described.  While an implementor should realize from
section 3.5 that the rank advertised by the neighbor is an
approximation for ETX and should be used here, the text as written is
incomplete.

2. Also for completeness, the document should specify the
representation used for ETX to be used in path cost computation; e.g.,
as specified for the ETX sub-object in RFC 6551.

3. Related to point 2, explanation of the relationship between the
representation used for ETX and rank should be explained, especially
considering what I think will be unexpected side effects of the value
of DEFAULT_MIN_HOP_RANK_INCREASE defined to be 256 in RFC 6550
interacting with the (presumed) default representation of ETX as
defines in RFC 6551.

4.  In section 3.4:

  If ETX is the selected metric, a node SHOULD NOT advertise it in a
  metric container.

s/SHOULD NOT/MUST NOT/ (and this text is redundant relative to the
last sentence of section 3.5).

5. Are the parameter values in section 5 recommended only for use when
the selected metric is ETX; seems to me MAX_LINK_METRIC, MAX_PATH_COST
and PARENT_SWITCH_THRESHOLD depend on the selected metric and the
recommended values wouldn't make much sense for, e.g., hop count.

These comments are purely editorial and offered to improve the clarity
of the document.

1. The paragraph immediately following table seems superfluous.  The
list of metrics for which the rank is undefined is not complete (from
RFC 6551).  The paragraph begs the question "why would the deployment
choose a metric for which the rank is undefined?"

2. Readability would be improved by writing the details of the
special-case treatment of ETX (currently in section 3.5) to the point
at which that special-case treatment modifies other behavior specified
in the document; e.g., the second component of the path cost cited
above.

3. The second sentence of section 6 is pretty opaque.  Is the point
that the "List of supported metrics" from section 18.2.3 need not be
supported if MRHOF is used?

4. Isn't the last paragraph of section 6.1 true for any selected metric?
2012-07-07
11 Ralph Droms [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss
2012-07-03
11 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss
2012-07-03
11 Martin Stiemerling [Ballot comment]
I have cleared and thank you for addressing my concerns.
2012-07-03
11 Martin Stiemerling [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss
2012-06-29
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-06-29
11 Omprakash Gnawali New version available: draft-ietf-roll-minrank-hysteresis-of-11.txt
2012-05-10
10 Amy Vezza State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation
2012-05-10
10 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2012-05-10
10 Ralph Droms
[Ballot discuss]
These Discuss points are all intended to ask about design
decisions and suggest clarifications.  No action is required
by the authors until these …
[Ballot discuss]
These Discuss points are all intended to ask about design
decisions and suggest clarifications.  No action is required
by the authors until these points have been discussed.

(Updated at last edit with points 6 and 7.)

1.  Why is one objective function defined for several potential
metrics?  The details of MRHOF seem to preclude the establishment of
several RPL instances in an LLN, each of which uses MRHOF with a
different selected metric.

2. How are the nodes in the RPL instance informed about the selected
metric?  My understanding of RPL is that only the objective function
is included in the DIO received as an advertisement for a particular
RPL instance, which means a node can't know the selected metric for
that RPL instance and can't meaningfully decide among multiple RPL
instances all using MRHOF as the objective function.

As a followup to (1), if there were a way to encode the selected
metric for a RPL instance in the DAO, a node would be able to select
which RPL instance to use for a particular type of traffic.

3. Based on (1) and (2), would configuration and selection issues be
ameliorated if the five candidate selected metrics were each asssigned
a separate objective function?  Use of a separate OF code point for
each of the five possible selected metrics would allow multiple RPL
instances.

4. Related to the above, I don't see anything in section 6 about
managing the selected metric.  Don't all of the nodes that join a RPL
instance using MRHOF have to be configured to use the same selected
metric?

5. In section 3.2.2:

  a
  node MAY use a different objective function to select which of these
  neighbors should be considered to have the lowest cost.

seems to contradict the statement in the Introduction that "all nodes
in a network use a common OF."  Should "different objective function"
be replaced with "some other selection criteria?"

6. In section 5, are the RECOMMENDED values appropriate for all
selected metrics or just for ETX?  Are there any references that might
be cited that would give background on the working group experience
with ETX and the development of the recommended values?

7. In section 6.1, why not "MUST support the DODAG Configuration
option?"  I don't see any RFC 2119 requirements on the implementation
of the DODAG Configuration option (which would appera to be an
oversight), but I don't understand how a node can operate in a RPL
instance without, for example, being able to determine the Objective
Function used by that instance.
2012-05-10
10 Ralph Droms Ballot discuss text updated for Ralph Droms
2012-05-10
10 Ralph Droms
[Ballot discuss]
These Discuss points are all intended to ask about design
decisions and suggest clarifications.  No action is required
by the authors until these …
[Ballot discuss]
These Discuss points are all intended to ask about design
decisions and suggest clarifications.  No action is required
by the authors until these points have been discussed.

1.  Why is one objective function defined for several potential
metrics?  The details of MRHOF seem to preclude the establishment of
several RPL instances in an LLN, each of which uses MRHOF with a
different selected metric.

2. How are the nodes in the RPL instance informed about the selected
metric?  My understanding of RPL is that only the objective function
is included in the DIO received as an advertisement for a particular
RPL instance, which means a node can't know the selected metric for
that RPL instance and can't meaningfully decide among multiple RPL
instances all using MRHOF as the objective function.

As a followup to (1), if there were a way to encode the selected
metric for a RPL instance in the DAO, a node would be able to select
which RPL instance to use for a particular type of traffic.

3. Based on (1) and (2), would configuration and selection issues be
ameliorated if the five candidate selected metrics were each asssigned
a separate objective function?  Use of a separate OF code point for
each of the five possible selected metrics would allow multiple RPL
instances.

4. Related to the above, I don't see anything in section 6 about
managing the selected metric.  Don't all of the nodes that join a RPL
instance using MRHOF have to be configured to use the same selected
metric?

5. In section 3.2.2:

  a
  node MAY use a different objective function to select which of these
  neighbors should be considered to have the lowest cost.

seems to contradict the statement in the Introduction that "all nodes
in a network use a common OF."  Should "different objective function"
be replaced with "some other selection criteria?"
2012-05-10
10 Ralph Droms
[Ballot comment]
These Comment points are non-blocking editorial suggestions.

1. In the Introduction, s/OF/objective function/ ; the abbreviation OF
doesn't appear to be used anywhere …
[Ballot comment]
These Comment points are non-blocking editorial suggestions.

1. In the Introduction, s/OF/objective function/ ; the abbreviation OF
doesn't appear to be used anywhere else in the document.

2. Is the second paragraph in section 3.1 equivalent to writing:

  If a non-root node does not have metrics to compute the path cost
  through any of the candidate neighbors, [...]
2012-05-10
10 Ralph Droms [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms
2012-05-09
10 Wesley Eddy [Ballot comment]
I support point 2 of Brian's DISCUSS.
2012-05-09
10 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2012-05-09
10 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2012-05-09
10 Stephen Farrell
[Ballot comment]
- Hysteresis could do with a definition - many non-native
English speakers (and native speakers!) might have to go
look it up so …
[Ballot comment]
- Hysteresis could do with a definition - many non-native
English speakers (and native speakers!) might have to go
look it up so why not save them the trouble?

- ETX is used without expansion of reference in the intro.
Link color is used in 3.3 but not defined. It'd be good to
be clearer that those are defined in 6551.

- This smells experimental to me. I wondered if it had
already been implemented/tested. (Not a requirement
for PS, so I'm just asking.)

- You RECOMMEND use of security mechanisms if there is a
risk. Can't you be more specific on which security
mechanism you mean (e.g.  referring to the right bit of
6550, maybe 10.6)? I've not made this a discuss since I
hold one on the security framework and perhaps the
inability to pick something concrete here will be resolved
as a side-effect of that.
2012-05-09
10 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2012-05-09
10 Stewart Bryant [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant
2012-05-08
10 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2012-05-08
10 Adrian Farrel Ballot writeup was changed
2012-05-07
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica
2012-05-07
10 Miguel García Request for Telechat review by GENART Completed. Reviewer: Miguel Garcia.
2012-05-07
10 Robert Sparks
[Ballot comment]
I made the same observations in my review that Barry reports in his comments. Please also consider clarifying that no one node sums …
[Ballot comment]
I made the same observations in my review that Barry reports in his comments. Please also consider clarifying that no one node sums up the values of the selected metrics in the definition of path cost - rather, each node adds to the cost reported by the parent (section 3.1) resulting in a total for the path.
2012-05-07
10 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2012-05-07
10 Martin Stiemerling
[Ballot discuss]
Section 3., paragraph 1:

>    This computation MAY also be performed periodically.  Too much delay
>    in updating the path cost …
[Ballot discuss]
Section 3., paragraph 1:

>    This computation MAY also be performed periodically.  Too much delay
>    in updating the path cost after the metric is updated or a new metric
>    advertisement is received can lead to stale information.

  Is there any recommendation or further reading on what the time is
  to be used to perform the periodically updates?
  Re-computing state periodically might be a good thing, but I would expect that a Standards Track document is much more specific on this.


Section 2., paragraph 1:

>    The parent selection MAY be deferred until a later time.  Deferring
>    the parent selection can delay the use of better paths available in
>    the network.

  How much is the 'later time'?
  I would expect that a Standards Track document is much more specific on this, other than do whatever you think is appropriate.


Section 5., paragraph 9:

>    The parameter values are assigned depending on the selected metric.
>    The best values for these parameters should be experimentally
>    determined.  The working group has long experience routing with the
>    ETX metric.  Based on those experiences, these values are
>    RECOMMENDED:

  Is there any reference on how the WG came to the below numbers? This
  would be good for people trying to follow this up in the future. They
  might need to know how to came to these numbers.
2012-05-07
10 Martin Stiemerling
[Ballot comment]
- I support Barry's comment on SHOULD/MAY usage
- More points here:

Section 1., paragraph 1:

>    An objective function specifies how …
[Ballot comment]
- I support Barry's comment on SHOULD/MAY usage
- More points here:

Section 1., paragraph 1:

>    An objective function specifies how RPL [RFC6550] selects paths.  For
>    example, if an RPL instance uses an objective function that minimizes
>    hop-count, RPL will select paths with minimum hop count.  RPL
>    requires that all nodes in a network use a common OF; relaxing this
>    requirement may be a subject of future study.

  Expand abbreviation OF on first use.


Section 1., paragraph 4:

>    This specification describes MRHOF, an objective function for RPL.
>    MRHOF uses hysteresis while selecting the path with the smallest
>    metric value.  The metric that MRHOF uses is determined by the
>    metrics in the DIO Metric Container.  For example, the use of MRHOF
>    with the latency metric allows RPL to find stable minimum-latency
>    paths from the nodes to a root in the DAG instance.  The use of MRHOF
>    with the ETX metric allows RPL to find the stable minimum-ETX paths
>    from the nodes to a root in the DAG instance.  In the absence of a
>    metric in the DIO Metric Container or the lack of a DIO Metric
>    Container, MRHOF defaults to using ETX to compute Rank, as described
>    in Section 3.5.

  Expand abbreviation MRHOF on first use (sort of first in the
  introduction). Expand DAG and ETX on first use, probably add
  reference.
2012-05-07
10 Martin Stiemerling [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling
2012-05-06
10 Russ Housley
[Ballot comment]

  Please consider the editorial issues raise in the Gen-ART Review by
  Miguel Garcia on 27-Mar-2012.  The review can be found here: …
[Ballot comment]

  Please consider the editorial issues raise in the Gen-ART Review by
  Miguel Garcia on 27-Mar-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07303.html
2012-05-06
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2012-05-03
10 Jean Mahoney Request for Telechat review by GENART is assigned to Miguel Garcia
2012-05-03
10 Jean Mahoney Request for Telechat review by GENART is assigned to Miguel Garcia
2012-05-02
10 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2012-05-02
10 Brian Haberman
[Ballot discuss]
I found this draft to be rather straightforward to understand, but have a few points I would like clarified (possibly just for me)... …
[Ballot discuss]
I found this draft to be rather straightforward to understand, but have a few points I would like clarified (possibly just for me)...

1. In sections 3.1 and 3.2.1, the draft says that messages can be delayed but should not be delayed too much?  How much is too much?  Is it dependent on the metric being used?  Are there guidelines that should be provided?  If different implementations try to interact, will their selection of delay values hinder performance/stability of the RPL-based network?

2. Section 5 says, "The best values for these parameters should be experimentally determined."  Is this guidance to implementers to figure out what values to support in their implementation or advice to operators to test a range of values for their particular deployment?  As a standards-track document, this type of nebulous statement concerns me from a variety of perspectives.

3. Section 8 asks IANA to allocate a code point, but where in the draft is that code point used? Is it used as a part of the transmission logic in section 3.4?
2012-05-02
10 Brian Haberman
[Ballot comment]
I support Barry's comment on the confusing use of SHOULDs+MAYs and would like to see those cleaned up.

1. The Introduction uses several …
[Ballot comment]
I support Barry's comment on the confusing use of SHOULDs+MAYs and would like to see those cleaned up.

1. The Introduction uses several acronyms without any expansion (OF, DAG, ETX).  These should be expanded on first use and possibly augmented with a reference (e.g., ETX).

2. Section 3.1 uses DODAG with no expansion or reference.

3. A forward pointer to section 5 in section 3.2.2 would make sense for the constants/variables referenced.
2012-05-02
10 Brian Haberman [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman
2012-04-29
10 Barry Leiba
[Ballot comment]
Substantive comments; please adopt or respond to these:

Nice, easy-to-read document.  Only one substantive comment, about 2119 language:

-- Section 3.2.1 --

The …
[Ballot comment]
Substantive comments; please adopt or respond to these:

Nice, easy-to-read document.  Only one substantive comment, about 2119 language:

-- Section 3.2.1 --

The use of SHOULD and MAY here is inconsistent -- the MAY turns the SHOULD into something more optional than a SHOULD ought to be.  I suggest not using MAY, and rephrasing this way (unless I misunderstand the meaning here):
NEW
   If, despite the above, it is necessary to defer the parent selection
   until a later time, note that doing so can delay the use of better
   paths available in the network.

========
Editorial suggestions.  No need to respond to these; take them or modify them as you please:

-- Section 1 --
   Because MRHOF seeks to minimize path costs as described by metrics,
   it can only be used with additive metrics.  MRHOF ignores metrics
   that are not additive.

Is it really "ignores"?  Or "does not support"?

-- Section 2 --
OLD
         Path cost is obtained by summing up the selected metric of the
         links or nodes along the path.
NEW
         Path cost is obtained by summing up the values of the selected
         metric for the links or nodes along the path.
2012-04-29
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2012-04-26
10 Pearl Liang
IESG:

IANA Actions - YES

NOTE: IANA has noted that the Description for the the new requested
value should be "The Minimum Rank with Hysteresis …
IESG:

IANA Actions - YES

NOTE: IANA has noted that the Description for the the new requested
value should be "The Minimum Rank with Hysteresis Objective Function
(MRHOF)" as per Michael Richardson. A value of 1 is suggested.

Please make sure to include the "Description" name for the value in
the IANA Considerations section.

http://www.iana.org/assignments/rpl/rpl.xml#ocp
2012-04-26
10 P Levis New version available: draft-ietf-roll-minrank-hysteresis-of-10.txt
2012-04-26
09 Adrian Farrel State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2012-04-26
09 Adrian Farrel Placed on agenda for telechat - 2012-05-10
2012-04-26
09 Adrian Farrel Ballot has been issued
2012-04-26
09 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2012-04-26
09 Adrian Farrel Created "Approve" ballot
2012-04-22
09 P Levis New version available: draft-ietf-roll-minrank-hysteresis-of-09.txt
2012-04-20
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-04-20
08 Omprakash Gnawali New version available: draft-ietf-roll-minrank-hysteresis-of-08.txt
2012-04-08
07 Adrian Farrel State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead
2012-04-06
07 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2012-03-30
07 Miguel García Request for Last Call review by GENART Completed. Reviewer: Miguel Garcia.
2012-03-16
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Carl Wallace
2012-03-16
07 Samuel Weiler Request for Last Call review by SECDIR is assigned to Carl Wallace
2012-03-15
07 Jean Mahoney Request for Last Call review by GENART is assigned to Miguel Garcia
2012-03-15
07 Jean Mahoney Request for Last Call review by GENART is assigned to Miguel Garcia
2012-03-14
07 Martin Stiemerling Request for Last Call review by TSVDIR is assigned to David Borman
2012-03-14
07 Martin Stiemerling Request for Last Call review by TSVDIR is assigned to David Borman
2012-03-12
07 Amy Vezza Last call sent
2012-03-12
07 Amy Vezza
State changed to In Last Call from Last Call Requested<br><br>The following Last Call Announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org><br><br>To: IETF-Announce …
State changed to In Last Call from Last Call Requested<br><br>The following Last Call Announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org><br><br>To: IETF-Announce <ietf-announce@ietf.org><br><br>CC: <roll@ietf.org><br><br>Reply-To: ietf@ietf.org<br><br>Subject: Last Call: <draft-ietf-roll-minrank-hysteresis-of-07.txt> (The Minimum Rank with Hysteresis Objective Function) to Proposed Standard<br><br><br><br><br><br>The IESG has received a request from the Routing Over Low power and Lossy<br><br>networks WG (roll) to consider the following document:<br><br>- 'The Minimum Rank with Hysteresis Objective Function'<br><br>  <draft-ietf-roll-minrank-hysteresis-of-07.txt> as a Proposed Standard<br><br><br><br>The IESG plans to make a decision in the next few weeks, and solicits<br><br>final comments on this action. Please send substantive comments to the<br><br>ietf@ietf.org mailing lists by 2012-04-06 (date set to longer than 2 weeks <br><br>to allow for IETF meeting). Exceptionally, comments may be<br><br>sent to iesg@ietf.org instead. In either case, please retain the<br><br>beginning of the Subject line to allow automated sorting.<br><br><br><br>Abstract<br><br><br><br>  The Routing Protocol for Low Power and Lossy Networks (RPL) uses<br><br>  objective functions to construct routes that optimize or constrain<br><br>  the routes it selects and uses.  This specification describes the<br><br>  Minimum Rank Objective Function with Hysteresis (MRHOF), an objective<br><br>  function that selects routes that minimize a metric, while using<br><br>  hysteresis to reduce churn in response to small metric changes.<br><br>  MRHOF works with metrics that are additive along a route, and the<br><br>  metric it uses is determined by the metrics RPL Destination<br><br>  Information Object (DIO) messages advertise.<br><br><br><br>The file can be obtained via<br><br>http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/<br><br><br><br>IESG discussion can be tracked via<br><br>http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ballot/<br><br><br><br><br><br>No IPR declarations have been submitted directly on this I-D.
2012-03-12
07 Adrian Farrel Last call was requested
2012-03-12
07 Adrian Farrel State changed to Last Call Requested from AD Evaluation::AD Followup
2012-03-12
07 Adrian Farrel Last call announcement was changed
2012-03-12
07 Adrian Farrel Last call announcement was generated
2012-03-12
07 Adrian Farrel Ballot writeup was changed
2012-03-09
07 P Levis New version available: draft-ietf-roll-minrank-hysteresis-of-07.txt
2012-03-06
06 P Levis New version available: draft-ietf-roll-minrank-hysteresis-of-06.txt
2012-03-04
05 (System) Sub state has been changed to AD Followup from Revised ID Needed
2012-03-04
05 P Levis New version available: draft-ietf-roll-minrank-hysteresis-of-05.txt
2011-09-27
04 (System) Ballot writeup text was added
2011-09-27
04 (System) Last call text was added
2011-09-27
04 (System) Ballot approval text was added
2011-09-27
04 Adrian Farrel Ballot writeup text changed
2011-09-27
04 Adrian Farrel
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review

Hi,

Here is my AD review of your draft. I was hoping to get …
State changed to AD Evaluation::Revised ID Needed from AD Evaluation.<br>AD review

Hi,

Here is my AD review of your draft. I was hoping to get away with a few
typos we could punt to a later stage, but I think there are a couple of
issues we need to iron out with a quick new revision.

I have put the I-D into "revised I-D needed" state and will issue the IETF Last Call when I see a new revision.

Thanks,
Adrian

---

In progressing the OG0 draft we learnt that there was no clear
understanding of what an objective function is. I think your draft does
a good job at explaining, but in an attempt to learn from the past, can
you please have a look at the text that got added to the OF0 document to
see whether anything can be added here.

---

Why is "Minimum Rank Objective Function with Hysteresis" MRHOF not
MROFH?

---

During the review process for OF0 we ended up adding the following
paragraph. Would you consider adding something similar to make this
point crystal clear?

  The RPL specification [I-D.ietf-roll-rpl] requires the use of a
  common OF by all nodes in a network.  The possible use of multiple
  OFs with a single network is for further study.

---

Section 2...

  This document introduces two terms:

There are three terms!

---

Section 5.1

Can you add a statement on default values?

Can you also have a look at Section 7 of the OF0 draft. This gives a
more substantive approach to describing manageability.

---

7.  IANA Considerations

You need to point the IANA at the specific registry. This would be the
"Objective Code Point (OCP)" sub-registry of the "Routing Protocol for
Low Power and Lossy Networks (RPL)" registry.

  This specification requires an allocated OCP.  A value of 1 is
  requested.

s/requested/suggested/

---

8.  Security Considerations

  Security considerations to be developed in accordance to the output
  of the WG.

I don't think we will get this past the Security directorate :-)

How about...

  This specification makes simple extensions to RPL and so is
  vulnerable to and benefits from the security issues and mechanisms
  described in [I-D.ietf-roll-rpl] and
  [I-D.ietf-roll-security-framework].  This document does not introduce
  new flows or new messages, thus requires no specific mitigation for
  new threats.

  MRHOF depends on information exchanged in a number RPL protocol
  elements.  If those elements were compromised, then an implementation
  of MRHOF might generate the wrong path for a packet, resulting in it
  being misrouted.  Therefore, deployments are RECOMMENDED to use RPL
  security mechanisms if there is a risk that routing information might
  be modified or spoofed.
2011-09-02
04 Adrian Farrel State changed to AD Evaluation from Publication Requested.
2011-08-18
04 Cindy Morgan
> (1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in …
> (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?

JP Vasseur 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?

The I-D has been discussed in details by a number of key members of the
Working group. Number of comments have been made on the mailing list
during WG Last Call and addressed in this revision.

> (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?

No 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.

The document is sound.

> (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?

Good consensus.

> (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 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].

References split has been done.

> (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?

The IANA action is properly documented.

> (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.
An objective function specifies how RPL [I-D.ietf-roll-rpl] selects
paths. Objective functions can choose paths based on routing metrics
or constraints. For example, if an RPL instance uses an objective
function that minimizes hop-count, RPL will select paths with minimum
hop count.

The nodes running RPL might use a number of metrics to describe a
link or a node [I-D.ietf-roll-routing-metrics] and make it available
for route selection. These metrics are advertised in RPL Destination
Information Object (DIO) messages using a Metric Container suboption.
An objective function can use these metrics to choose routes. The
only exception is the ETX metric, which is used without the metric
container as described in Section 3.5.

To decouple the details of an individual metric or objective function
from forwarding and routing, RPL describes routes through a value
called Rank. Rank, roughly speaking, corresponds to the distance
associated with a route. An objective function is responsible for
computing a node's advertised Rank value based on the Rank of its
potential parents, metrics, and other network properties.

This specification describes MRHOF, an objective function for RPL.
MRHOF uses hysteresis while selecting the path with the smallest
metric value. The metric that MRHOF uses is determined by the
metrics in the DIO Metric Container. For example, the use of MRHOF
with the latency metric allows RPL to find stable minimum-latency
paths from the nodes to a root in the DAG instance. The use of MRHOF
with the ETX metric allows RPL to find the stable minimum-ETX paths
from the nodes to a root in the DAG instance.

MRHOF can only be used with an additive metric that must be minimized
on the paths selected for routing.

> 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 discontent.

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

Yes there are several known implementations of these specification.
2011-08-18
04 Cindy Morgan Draft added in state Publication Requested
2011-08-18
04 Cindy Morgan [Note]: 'JP Vasseur (jpv@cisco.com) is the document shepherd.' added
2011-05-17
04 (System) New version available: draft-ietf-roll-minrank-hysteresis-of-04.txt
2011-05-03
03 (System) New version available: draft-ietf-roll-minrank-hysteresis-of-03.txt
2011-04-27
02 (System) New version available: draft-ietf-roll-minrank-hysteresis-of-02.txt
2011-03-01
01 (System) New version available: draft-ietf-roll-minrank-hysteresis-of-01.txt
2010-10-11
00 (System) New version available: draft-ietf-roll-minrank-hysteresis-of-00.txt