Subject: [Roll] I-D Action:draft-ietf-roll-of0-07.txt

From: [email-masked]
Date: Mon, 14 Mar 2011 02:45:01 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title           : RPL Objective Function 0
	Author(s)       : P. Thubert
	Filename        : draft-ietf-roll-of0-07.txt
	Pages           : 10
	Date            : 2011-03-14

The Routing Protocol for Low Power and Lossy Networks (RPL) defines a
generic Distance Vector protocol for Low Power and Lossy Networks
(LLNs).  RPL is instantiated to honor a particular routing objective/
constraint by the adding a specific Objective Function (OF) that is
designed to solve that problem.  This specification defines a basic
OF, OF0, that uses only the abstract properties exposed in RPL
messages with no metric container.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Philip Levis <[email-masked]>
Date: Tue, 15 Mar 2011 18:53:02 -0700

> ftp://ftp.ietf.org/internet-drafts/

Comments and suggested edits on OF0-07 follow. Because of the very short timeframe I am including concrete edits rather than general recommendations. My general read is that the core ideas of OF0 are sound but its current text is very much out of date with how RPL works: it has many holdovers from older specifications of RPL, such as siblings and how Rank is computed. Correspondingly it is very confusing and inconsistent with the core protocol. It also contradicts general practice in LLN routing, at least as far as I am aware of it. My edits try to fix this, as well as clean up a range of grammatical issues.

Abstract:
  
"RPL is instantiated to honor a particular routing objective/constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. "

should become

"A RPL instance specifies an Objective Function (OF) that defines how nodes in the instance compute distance and select routes."

Reason: "honor" is inaccurate, that suggests one could not follow it. It is not clear what "problem" the sentence refers to. "by the adding" is grammatically incorrect. I think the new sentence more clearly and accurately says what the existing one is trying to.

----

Introduction edit 1:

"Considering the wide variety of use cases, link types and metrics,
   the Routing Protocol for Low Power and Lossy Networks
   [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic
   to metrics and instantiated using Objective Functions.

   RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs)
   within instances of the protocol, each instance being set up to honor
   a particular routing objective/constraint of a given deployment.
   This instantiation is achieved by plugging into the RPL core a
   specific Objective Function (OF) that is designed to solve that
   problem to be addressed by that instance."

should become

"Considering the wide variety of use cases, link types and metrics,
   the Routing Protocol for Low Power and Lossy Networks
   [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic
   to metrics. Each RPL instance specifies an Objective Function which
   nodes in that instance use to compute and select routes. This separation
   of Objective Functions from the core protocol specification allows RPL
   to adapt to meet the different optimization criteria the wide range of
   use cases requires."

Reason: The second paragraph in the original version is confused: it suggests that one instantiates RPL by giving it an Objective Function. This is not true. Tries to explain the reason for the separation, rather than how it's used.

Introduction edit 2:

   "An Objective Function selects the DODAG version that a device joins,
   and a number of neighbor routers within that version as parents and
   siblings.  The OF is also responsible for computing the Rank of the
   device, that abstracts a relative position within the DODAG and is
   used by the RPL core to enable a degree of loop avoidance and verify
   forward progression towards a destination, as specified in
   [I-D.ietf-roll-rpl]."

should become

  "A RPL instance forms Destination Oriented Directed Acyclic Graphs (DODAGs).
   An Objective Function selects the DODAG that a device joins,
   the neighbor routers within that DODAG that the device maintains
   state on, and which neighbors the device selects as parents towards
   the root of the DODAG. The OF is also responsible for computing the Rank of the
   device, an abstract distance from the DODAG root."

Reason: There is no reason to talk about loop avoidance and datapath validation here. Siblings are no longer a primitive in RPL, the rewrite makes the above description accurately reflect the text in DIO processing in -19.

Introduction edit 3:

Cut the paragraph:    

"Indeed, it is the general design in RPL that the metrics are passed
   from parent to children in a specific container and that the OF will
   derive the Rank from the natural metric.  The separation of Rank and
   metrics avoids a loss of information as the various metrics are
   propagated down the DAG.  This specification can be used when the
   link properties that are considered are such that they can be turned
   in a scalar step of Rank in a reversible fashion and the resulting
   step of rank is additive over multiple hops."

Reason: this is unnecessary detail and just a restatement of RPL and makes this draft confusing, because it's describing a property of RPL that the draft does not use.

Introduction edit 4:

"OF0 does not leverage metric containers such as
   described in the metrics draft [I-D.ietf-roll-routing-metrics].  OF0
   does not require information in the RPL messages but the abstract
   information from the DIO base container, such as Rank and an
   administrative preference, that is transported in DIOs as
   DODAGPreference in [I-D.ietf-roll-rpl]."

should become

  "OF0 does not use RPL metric containers[I-D.ietf-roll-routing-metrics] and ignores them. OF0
   only requires the information in the DIO base container, such as Rank and the
   DODAGPreference field that describes an administrative preference[I-D.ietf-roll-rpl]."

Reason: The DODAGPreference is not transported in the draft; it's transported in a DIO Base container. It's better to say what OF0 requires, rather than what it doesn't require, as the latter is imprecise and open to interpretation (e.g. one could claim it needs information in a DIS).

------

Goal edit 1:

3. Goal

should become

3. Objective Function 0 Overview

Reason: This section is not just about goals, it is about how OF 0 works.

Goal edit 2:

   "The metric used in OF0 can be an administratively defined scalar cost
   that is trivially added up along a path to compute the RPL Rank, as
   defined in [I-D.ietf-roll-rpl].  Depending on how the step of Rank is
   computed by an implementation, the Rank of a node might be analogous
   to a weighted hop count of the path to the root.  Using a metric that
   in essence is similar to hop count implies that the quality of the
   connectivity should be asserted so that only neighbors with a good
   enough connectivity are presented to the OF.  How that connectivity
   is asserted and maintained is not covered by this specification.

   In wireless networks, Hop Count will tend to favor paths with long
   distance links and non optimal connectivity properties.  In some
   situations, this might end up partitioning the network.  As a result,
   the link selection must be very conservative, and the available link
   set is thus constrained.  For those reasons, though it can be used on
   wired links and wired link emulations such as WIFI infrastructure
   mode, a metric derived from hop count is generally not recommended
   for wireless networks.  Instead, careful thinking should be applied
   to determine how the step of Rank is computed from the link
   properties.  For instance, the Minimum Rank Objective Function with
   Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on
   how hysteresis can be used to maintain a certain stability of the
   resulting Rank."

should become

   "OF0 computes Rank as a simple scalar cost that nodes add up
   along a path. OF0 assigns a cost to each link to another node
   that it monitors and computes Rank as the Rank of the other node plus
   the cost of the link. The exact method for computing link cost is
   implementation-dependent.

   One trivial OF0 implementation might compute the Rank
   as a weighted hop count where some links cost more than one hop.  
   Using a metric similar to hop count implies that the OF0 implementation
   only considers neighbors with good enough connectivity, especially
   in wireless networks. In wireless networks, an unweighted hop count
   favors paths with long distance links and poor connectivity properties[De Couto].
   Wireless networks using OF0 should carefully compute the step of Rank
   from link properties to avoid this problem.  For instance, the Minimum 
   Rank Objective Function with Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] 
   provides guidance on how link cost can be computed and hysteresis can improve
   Rank stability."

Here's the reference:

[De Couto] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing, Proceedings of the 9th ACM International Conference on Mobile Computing and Networking (MobiCom ‘03), San Diego, California, September 2003.

Reason: The current text suggests hopcount as a mechanism, but then says that it's not advised for wireless networks. But this is not quite correct: OF0 uses a link weighting, which means it could work fine as long as you weight the links properly. The reference to MRHOF is also a non-sequitor: it jumps from cost computation to route selection hysteresis. Instead, MRHOF is relevant here because it talks about ways to compute Rank steps. The comment about WiFi should be removed because, well, it is wireless.

Goal edit 3:

All text in 3 after 
  "A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in
   order to enable the selection of a sibling when only one parent is
   available.  For instance, say that a node computes a step of Rank of
   4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank
   of 6 units resulting in a Rank of 10 units for this node.  Say that
   with that Rank of 10 units, this node would end up with only one
   parent and no sibling, though there is a neighbor with a Rank of 12
   units.  In that case, the node is entitled to stretch its step of
   Rank by a value of 2 units, thus using a step of Rank of 6 units so
   as to reach a Rank of 12 units and find a sibling.  But the node is
   not entitled to use a step of Rank larger than 6 units since that
   would be a greedy behavior that would deprive the neighbor of this
   node of a successor.  Also, if the neighbor had exposed a Rank of 16
   units, the stretch of Rank from 10 to 16 units would have exceeded
   MAXIMUM_RANK_STRETCH of 5 units and thus the neighbor would not have
   been selectable even as a sibling...."

should become

  "The core RPL specification describes constraints on how nodes select
   potential parents, called a parent set, from their neighbors. 
   OF0 selects a parent set trying to balance three needs.  The first is
   that the route through its preferred parent has as low a Rank as
   possible.  The second is that it has multiple elements in its parent
   set.  The third is that the Rank it sets for the node is not much
   higher than the Rank associated with the route through its preferred
   parent.  Generally, the first two are more important than the third:
   advertising a high Rank in order to maintain some path diversity is
   better than advertising a lower Rank but being unable to route when
   the corresponding link fails.

   OF0 has a parameter, MAXIMUM_RANK_STRETCH, which defines the maximum
   stretch between the associated Rank of members of its parent set.
   If the Rank associated with a route through a node's preferred parent is
   R, then the node MUST NOT advertise a Rank greater than 
   R + MAXIMUM_RANK_STRETCH.

   OF0 has two rules when selecting the DODAG Version of its parent set.
   First, OF0 MUST select a parent set from a DODAG Version that has the
   highest administrative preference among the DODAG Versions it is aware 
   of. Among the DODAGs with this highest administrative preference value,
   OF0 MUST select a Grounded DODAG if one is available."

Reason: the current text talks about stretching Rank to reach siblings without first saying how Rank is computed. Siblings are no longer a concept in RPL. The concepts are neighbor set, parent set, and preferred parent. The edit clearly states how preferred parents are selected, the parent set is selected, etc. The statements about Grounded and administrative preference are not normative, yet should be. The rule on MAXIMUM_RANK_STRETCH is now defined properly in line with how parent sets affect DIO processing.

Goal edit 4:

Remove section 4: it contradicts itself several times. For example, 6 says that one SHOULD use a newer DODAG Version; 9 says that one SHOULD use the existing DODAG Version. Furthermore, it is not clear that the actual order specified is the right one (it is not based on any existing implementations). Rule 4 is subsumed in the Goal edit 3 text, as is rule 5. Rule 7 (minimize Rank) will cause route flapping because it comes before rule 10 (keep existing preferred parent).

Goal edit 5:

Remove section 5: the abstraction of a parent set in the RPL core specification removes the need for a backup next hop: every element of the parent set is a backup next hop. This section could be rewritten to reflect a parent set, but Goal edit 3 addresses this somewhat.

If you think section 4 and 5 should stay, I can try a rewrite that would make them consistent with the DIO processing rules in -19 as well as not contradictory and applicable to wireless networks.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Mar 2011 16:11:53 +0100

Thanks a lot for all this Phil,

[Pascal] Please find some answers below. I'd really appreciate that
others comment about this.

> Comments and suggested edits on OF0-07 follow. Because of the very
short
> timeframe I am including concrete edits rather than general
> recommendations. My general read is that the core ideas of OF0 are
sound
> but its current text is very much out of date with how RPL works: it
has many
> holdovers from older specifications of RPL, such as siblings and how
Rank is
> computed. Correspondingly it is very confusing and inconsistent with
the
> core protocol. It also contradicts general practice in LLN routing, at
least as far
> as I am aware of it. My edits try to fix this, as well as clean up a
range of
> grammatical issues.
> 
> Abstract:
> 
> "RPL is instantiated to honor a particular routing
objective/constraint by the
> adding a specific Objective Function (OF) that is designed to solve
that
> problem. "
> 
> should become
> 
> "A RPL instance specifies an Objective Function (OF) that defines how
nodes
> in the instance compute distance and select routes."

[Pascal] 
The term instantiated here refers to the fact that RPL as a protocol has
a generic core. To turn it into an runnable protocol, it has to be
instantiated by adding and OF. The result is a protocol.
Your words are correct but refer to a different thing. A RPL instance is
a runtime construct. There is no need to redefine it here.

> 
> Reason: "honor" is inaccurate, that suggests one could not follow it.
It is not
> clear what "problem" the sentence refers to. "by the adding" is
> grammatically incorrect. I think the new sentence more clearly and
accurately
> says what the existing one is trying to.
 
[Pascal] the grammar will be fixed by the RFC editor. Maybe achieve
would be better than honor?

> Reason: The second paragraph in the original version is confused: it
suggests
> that one instantiates RPL by giving it an Objective Function. This is
not true.

[Pascal] Well yes it is true. But we are referring to different things.

> Tries to explain the reason for the separation, rather than how it's
used.
[Pascal] I like your last sentence though.

>    the root of the DODAG. The OF is also responsible for computing the
Rank
> of the
> Reason: There is no reason to talk about loop avoidance and datapath
> validation here. Siblings are no longer a primitive in RPL, the
rewrite makes
> the above description accurately reflect the text in DIO processing in
-19.

[Pascal] I suggest we discuss the sibling separately, see if the
resolution is to introduce them in this spec or remove all that's
related to sibling.
This being said, I can agree that we do not need to define Rank anymore
that we need to define RPL Instance. I'm fine with the removal though
the existing text does not hurt IMHO.

> Reason: this is unnecessary detail and just a restatement of RPL and
makes
> this draft confusing, because it's describing a property of RPL that
the draft
> does not use.

[Pascal] this paragraph was added to clear things up based on your
comments (and Om's)
I could remove the first half though again I do not see any arm in it.
The second half " This specification can be used ... " seems a bit more
important unless you consider that all metrics can be turned into an
additive step of rank?

>   "OF0 does not use RPL metric
containers[I-D.ietf-roll-routing-metrics] and
> ignores them. OF0
>    only requires the information in the DIO base container, such as
Rank and
> the
>    DODAGPreference field that describes an administrative
preference[I-
> D.ietf-roll-rpl]."
> 
> Reason: The DODAGPreference is not transported in the draft; it's
> transported in a DIO Base container. It's better to say what OF0
requires,
> rather than what it doesn't require, as the latter is imprecise and
open to
> interpretation (e.g. one could claim it needs information in a DIS).
> 
[Pascal]  Makes sense to me; I trust that we can push that straight to
the RFC editor.

> Reason: This section is not just about goals, it is about how OF 0
works.
[Pascal] OK

>    favors paths with long distance links and poor connectivity
properties[De
> Couto].
>    Rank Objective Function with Hysteresis
[I-D.ietf-roll-minrank-hysteresis-
> of]
>    provides guidance on how link cost can be computed and hysteresis
can
> improve
>    Rank stability."
> 
> Here's the reference:
> 
> [De Couto] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and
Robert
> Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing,
> Proceedings of the 9th ACM International Conference on Mobile
Computing
> and Networking (MobiCom '03), San Diego, California, September 2003.
> 
> Reason: The current text suggests hopcount as a mechanism, but then
says
> that it's not advised for wireless networks. But this is not quite
correct: OF0
> uses a link weighting, which means it could work fine as long as you
weight
> the links properly. The reference to MRHOF is also a non-sequitor: it
jumps
> from cost computation to route selection hysteresis. Instead, MRHOF is
> relevant here because it talks about ways to compute Rank steps. The
> comment about WiFi should be removed because, well, it is wireless.
> 
[Pascal] Very good

>    OF0 MUST select a Grounded DODAG if one is available."
: the current text talks about stretching Rank to reach siblings without
> first saying how Rank is computed. Siblings are no longer a concept in
RPL.
> The concepts are neighbor set, parent set, and preferred parent. The
edit
> clearly states how preferred parents are selected, the parent set is
selected,
> etc. The statements about Grounded and administrative preference are
not
> normative, yet should be. The rule on MAXIMUM_RANK_STRETCH is now
> defined properly in line with how parent sets affect DIO processing.
> 

[Pascal] Note that the stretch is associated to siblings. It is the
stretch between Rank obtained from the preferred parent and a sibling,
not the license to go deeper to get an alternate parent, which would be
a bit greedy. I expected this text to go down the sink with the sibling
text. What you're doing here changes the meaning of stretch
considerably. This would be a new behavior and thus a new LC. 

> Reason
> Goal edit 4:
> 
> Remove section 4: it contradicts itself several times. For example, 6
says that
> one SHOULD use a newer DODAG Version; 9 says that one SHOULD use the
> existing DODAG Version. Furthermore, it is not clear that the actual
order
> specified is the right one (it is not based on any existing
implementations).
> Rule 4 is subsumed in the Goal edit 3 text, as is rule 5. Rule 7
(minimize Rank)
> will cause route flapping because it comes before rule 10 (keep
existing
> preferred parent).

[Pascal] There is no contradiction. This really boils down to 9 is
useless and can be safely removed.

Rule 7 would cause flapping if the Rank changes are not dampened. But
the spec indicates that they should be. 10 before 7 would lock to a
parent forever.

Finally this text was reviewed by the group and is normative. 
So it was implemented by those who implemented OF0. We did not get a
feedback that the order was wrong. 
And since we passed LC, I'm not anxious to make any change there (but
remove the useless 9).

> Goal edit 5:
> 
> Remove section 5: the abstraction of a parent set in the RPL core
> specification removes the need for a backup next hop: every element of
the
> parent set is a backup next hop. This section could be rewritten to
reflect a
> parent set, but Goal edit 3 addresses this somewhat.

[Pascal] OF0 only requires one backup. But I agree it does not preclude
having more. And I agree that alt parents are all possible backups. But
I want to insist that a backup is not necessarily a parent.

> If you think section 4 and 5 should stay, I can try a rewrite that
would make
> them consistent with the DIO processing rules in -19 as well as not
> contradictory and applicable to wireless networks.

[Pascal] I do not think we have choice about that: the sections are
normative and should stay consistent to what they were at LC, unless we
have an IESG issue.
Text improvements that reduce the chances for a misunderstanding within
those constraints are welcome.

Let's talk in Prague.

Cheers,

Pascal

---

From: Philip Levis <[email-masked]>
Date: Wed, 16 Mar 2011 09:13:18 -0700

> a runtime construct. There is no need to redefine it here.

I think this is -- at least to me -- a confusing use of the word "instantiate." Adding an OF doesn't instantiate RPL: having a DODAG Root does. Of course, for a DODAG Root to exist there must be an OF selected for the corresponding RPL instance. Or are you saying you can have zero nodes yet have a RPL instance? The problem is that "RPL Instance" is defined in -19 as:

   RPL Instance:  A set of one or more DODAGs that share a
         RPLInstanceID.  A RPL node can belong to at most one DODAG in a
         RPL Instance.  Each RPL Instance operates independently of
         other RPL Instances.  This document describes operation within
         a single RPL Instance.

When I read "instantiate" I think "make a RPL Instance." Adding an OF to RPL does not create a RPL Instance, right?

> would be better than honor?

I think "meet" would possibly make more sense. But regardless, the second sentence doesn't make a lot of sense as it is.

> [Pascal] Well yes it is true. But we are referring to different things.

Please refer to the RPL Instance definition above.

> the existing text does not hurt IMHO.

There was a long discussion among the WG and authors remove the concept of siblings from RPL because they were confusing and not actually relevant to the protocol as it's now defined: they were another abstraction that just make the whole thing more complicated. Reintroducing the concept here seems contrary to that consensus.

> important unless you consider that all metrics can be turned into an

I don't think it's necessary. All that's needed is the clear statement (which the draft has) that OF0 ignores metric containers.

> considerably. This would be a new behavior and thus a new LC. 

But RPL does not have a concept of siblings! I know you love them but PLEASE don't try to reintroduce the concept. Doing so is tremendously confusing. We all agreed to remove siblings. You need to respect that decision rather than try to push RPL back in the direction you preferred.

More generally, after reading OF0-07 very carefully, I think you need to re-read the DIO processing rules in RPL-19. The current OF0 text is based on a very old version of RPL (makes sense, given it's been around since then) and is no longer consistent with current descriptions of the protocol.

> useless and can be safely removed.

I think removing 9. makes sense. 

Part of the issue here is that all of the rules are SHOULDs. This means one can write an OF0 which follows none of them yet still follows the RFC. 

I see two ways of reconciling 7 and 10.

1) Tweak the text in 7 to say 

   7.   When computing a resulting Rank for this node from a parent Rank
        and a Step of Rank from that parent, a parent that results in a significantly
        lower Rank than the current preferred parent SHOULD be preferred.

or merge 7 and 10

    7. The preferred parent that was already in use SHOULD be preferred, unless there is another element of the parent set which results in a significantly lower Rank, in which case this parent SHOULD be preferred.

> And since we passed LC, I'm not anxious to make any change there (but

I don't think this is the correct way to interpret the process. We are in LC now. The prior version, which passed LC, said "OF0 is not for wireless." This version says that OF0 can be used for wireless. So I am giving technical comments that allow it to make that claim.

Can someone who has implemented OF0 to follow the rules in Section 4 speak up and attest to their correctness? They seem to contradict what I understand distance vector calculations in wireless networks normally do. Of course, since all of the rules in 4 are SHOULDs, it is possible to write any algorithm and have it "follow" OF0. That doesn't mean we shouldn't try to provide guidance on what is the right thing to do in the general case.

> I want to insist that a backup is not necessarily a parent.

Please read the DIO processing rules of RPL-19. By definition, it may need to be, because of the rules on MaxRankIncrease.

> normative and should stay consistent to what they were at LC, unless we

Please note as above, we are in LC. The point of this LC is to make sure that OF0 can be applied to wireless, because of changes in the RPL spec in IESG review that made OF0 a SHOULD. The fact that it went through LC when it said it was not intended for wireless is not particularly relevant.

> those constraints are welcome.

I think you are incorrectly constraining the document.

Phil

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 17 Mar 2011 00:00:00 +0200

Hi,

I looked at the RPL spec, and there is indeed no mentioning of siblings.
Therefore, I think Phil has a point that it is out of context in OF0 from
the main body of RPL.

However, seeing the potential benefit by the use of siblings - is there a
method by which the related text on sibling becomes an optional feature
(maybe specified in a separate I-D)?

Best regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Philip Levis
Sent: Wednesday, March 16, 2011 6:13 PM
To: Pascal Thubert (pthubert)
Cc: ROLL WG
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt

> a runtime construct. There is no need to redefine it here.

I think this is -- at least to me -- a confusing use of the word
"instantiate." Adding an OF doesn't instantiate RPL: having a DODAG Root
does. Of course, for a DODAG Root to exist there must be an OF selected
for the corresponding RPL instance. Or are you saying you can have zero
nodes yet have a RPL instance? The problem is that "RPL Instance" is
defined in -19 as:

When I read "instantiate" I think "make a RPL Instance." Adding an OF to
RPL does not create a RPL Instance, right?

> would be better than honor?

I think "meet" would possibly make more sense. But regardless, the second
sentence doesn't make a lot of sense as it is.

> the existing text does not hurt IMHO.

There was a long discussion among the WG and authors remove the concept of
siblings from RPL because they were confusing and not actually relevant to
the protocol as it's now defined: they were another abstraction that just
make the whole thing more complicated. Reintroducing the concept here
seems contrary to that consensus.

> important unless you consider that all metrics can be turned into an

I don't think it's necessary. All that's needed is the clear statement
(which the draft has) that OF0 ignores metric containers.

> considerably. This would be a new behavior and thus a new LC.

But RPL does not have a concept of siblings! I know you love them but
PLEASE don't try to reintroduce the concept. Doing so is tremendously
confusing. We all agreed to remove siblings. You need to respect that
decision rather than try to push RPL back in the direction you preferred.

More generally, after reading OF0-07 very carefully, I think you need to
re-read the DIO processing rules in RPL-19. The current OF0 text is based
on a very old version of RPL (makes sense, given it's been around since
then) and is no longer consistent with current descriptions of the
protocol.

Part of the issue here is that all of the rules are SHOULDs. This means
one can write an OF0 which follows none of them yet still follows the RFC.

   7.   When computing a resulting Rank for this node from a parent Rank
        and a Step of Rank from that parent, a parent that results in a
significantly
        lower Rank than the current preferred parent SHOULD be preferred.

or merge 7 and 10

    7. The preferred parent that was already in use SHOULD be preferred,
unless there is another element of the parent set which results in a
significantly lower Rank, in which case this parent SHOULD be preferred.

> And since we passed LC, I'm not anxious to make any change there (but

I don't think this is the correct way to interpret the process. We are in
LC now. The prior version, which passed LC, said "OF0 is not for
wireless." This version says that OF0 can be used for wireless. So I am
giving technical comments that allow it to make that claim.

Can someone who has implemented OF0 to follow the rules in Section 4 speak
up and attest to their correctness? They seem to contradict what I
understand distance vector calculations in wireless networks normally do.
Of course, since all of the rules in 4 are SHOULDs, it is possible to
write any algorithm and have it "follow" OF0. That doesn't mean we
shouldn't try to provide guidance on what is the right thing to do in the
general case.

> I want to insist that a backup is not necessarily a parent.

Please read the DIO processing rules of RPL-19. By definition, it may need
to be, because of the rules on MaxRankIncrease.

> normative and should stay consistent to what they were at LC, unless we

Please note as above, we are in LC. The point of this LC is to make sure
that OF0 can be applied to wireless, because of changes in the RPL spec in
IESG review that made OF0 a SHOULD. The fact that it went through LC when
it said it was not intended for wireless is not particularly relevant.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 17 Mar 2011 09:44:18 +0100

Hi Phil

> > The term instantiated here refers to the fact that RPL as a protocol
> > has a generic core. To turn it into an runnable protocol, it has to
be
> > Your words are correct but refer to a different thing. A RPL
instance
> > is a runtime construct. There is no need to redefine it here.
> 
"instantiate."
> Adding an OF doesn't instantiate RPL: having a DODAG Root does. Of
course,
> for a DODAG Root to exist there must be an OF selected for the
> corresponding RPL instance. Or are you saying you can have zero nodes
yet
> have a RPL instance? The problem is that "RPL Instance" is defined in
-19 as:
> When I read "instantiate" I think "make a RPL Instance." Adding an OF
to RPL
> does not create a RPL Instance, right?

[Pascal] Yes. I do see why you feel that instantiate is ill chosen. 
I'm trying to convey the message that OF is an abstract interface that
needs to be implemented.
When an OF is plugged in, RPL becomes a complete protocol.
IOW, RPL is really a generic class of protocol, that cannot run by
itself.
The difference between this and classical TLVs in other protocols is
that the OF implies executable code.
Suggestion?

[Pascal] OK

> Please refer to the RPL Instance definition above.

[Pascal] This text does not have 'RPL Instance' . But then again I can
see why you feel we should avoid the term instantiate.

> > This being said, I can agree that we do not need to define Rank
> > anymore that we need to define RPL Instance. I'm fine with the
removal
> > though the existing text does not hurt IMHO.
> 
> There was a long discussion among the WG and authors remove the
concept
> of siblings from RPL because they were confusing and not actually
relevant to
> seems contrary to that consensus.

[Pascal] The sibling discussion is happening. Note that there was no
consensus but a shepherd decision.

> > comments (and Om's) I could remove the first half though again I do
> > not see any arm in it.
> > The second half " This specification can be used ... " seems a bit
> > more important unless you consider that all metrics can be turned
into
> > an additive step of rank?
> 
(which the
> draft has) that OF0 ignores metric containers.

[Pascal] Mr Hof has similar wording. I find it useful though no designed
in his
 right mind would use step of rank that cannot be added up.
So I do not mind either way.

> > not the license to go deeper to get an alternate parent, which would
> > be a bit greedy. I expected this text to go down the sink with the
> > sibling text. What you're doing here changes the meaning of stretch

[Pascal] The question here is the stretch. All I'm saying is that the
stretch was
defined by OF 0 for the sibling operation. Sibling goes away => stretch
goes away.

> 
> More generally, after reading OF0-07 very carefully, I think you need
to re-
> read the DIO processing rules in RPL-19. The current OF0 text is based
on a
> very old version of RPL (makes sense, given it's been around since
then) and
> is no longer consistent with current descriptions of the protocol.

[Pascal] I can do the exercise, no problem. But at the moment I do not
see an issue.

> I think removing 9. makes sense.

[Pascal] Agreed. I don't see a problem to remove it. Anyone?

> 
> Part of the issue here is that all of the rules are SHOULDs. This
means one can
> write an OF0 which follows none of them yet still follows the RFC.
> 
[Pascal] looks good

> significantly lower Rank, in which case this parent SHOULD be
preferred.
[Pascal] Not as good because the same parent check currently comes after
8 and 9.
This brings it up 2 steps.

> I don't think this is the correct way to interpret the process. We are
in LC
> now. The prior version, which passed LC, said "OF0 is not for
wireless." This
> version says that OF0 can be used for wireless. So I am giving
technical
> comments that allow it to make that claim.
> 
> Can someone who has implemented OF0 to follow the rules in Section 4
> speak up and attest to their correctness? They seem to contradict what
I
> understand distance vector calculations in wireless networks normally
do. Of

[Pascal] Could you please elaborate? 

> course, since all of the rules in 4 are SHOULDs, it is possible to
write any
> algorithm and have it "follow" OF0. That doesn't mean we shouldn't try
to
> provide guidance on what is the right thing to do in the general case.

[Pascal] My implementation follows this logic.
It was tested in wired and wireless environments though not on 802.15.4.

> > [Pascal] OF0 only requires one backup. But I agree it does not
> > preclude having more. And I agree that alt parents are all possible
> > backups. But I want to insist that a backup is not necessarily a
parent.
> 
> Please read the DIO processing rules of RPL-19. By definition, it may
need to
> be, because of the rules on MaxRankIncrease.

[Pascal] 
The transition between a version and the next requires to be able to
send to a parent on the next version when self has not made the step
yet.
I'll review the MaxRankIncrease text in that light but I do hope there's
no contradiction.

> > normative and should stay consistent to what they were at LC, unless
> > we have an IESG issue.
> 
> Please note as above, we are in LC. The point of this LC is to make
sure that
> OF0 can be applied to wireless, because of changes in the RPL spec in
IESG
> review that made OF0 a SHOULD. The fact that it went through LC when
it
> said it was not intended for wireless is not particularly relevant.

[Pascal] LC was terminated on the 10th of March. We are actually fixing
the issues that were opened but not resolved at that time.
It seems that the shepherd (JP) agrees to reopen the sibling discussion,
but we cannot rework the whole doc. 
And the RFC editor will fix the language, don't worry about that.

Pascal

Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05
From: "JP Vasseur" <[email-masked]>
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Date: Thu, 10 Mar 2011 18:08:42 +0100

Dear all,

This terminates the WG LC. Pascal, I think that you answered one of the comments
and asked for clarification on the second one. Could you get in touch with Phil who
commented, make sure that you addressed his point (I think that there still one
unresolved issue) and post the new revision ?

Thanks.

JP.

On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote:

Dear all,

This document has been stable for quite some time and the latest revision has addressed all comments received so far. This starts a 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon ET.

Please send your comments to the authors and copy the mailing list.

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Sat, 19 Mar 2011 15:46:39 -0700

> And the RFC editor will fix the language, don't worry about that.

I thought JP re-opened the last call until the 21st because the changes between -05 and -07 were very significant? Here's the message:

On Mar 14, 2011, at 8:50 AM, JP Vasseur wrote:

> Dear Working Group,
> 
> Since some of changes took place at the very last minute, I would like to start another WG Last Call on the
> revision 07 of draft-ietf-roll-of0 that end on March 21 at noon ET. Please send your comments to the Author
> and copy the mailing list.
> 
> Thanks.
> 
> JP.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Mar 2011 08:51:45 +0100

Sorry Phil, I had missed that. Back to the discussion then.

Pascal
http://www.xtranormal.com/watch/7011357/

> From: Philip Levis [mailto:[email-masked]]
> Sent: Saturday, March 19, 2011 11:47 PM
> > [Pascal] LC was terminated on the 10th of March. We are actually
> > fixing the issues that were opened but not resolved at that time.
> > It seems that the shepherd (JP) agrees to reopen the sibling
> > discussion, but we cannot rework the whole doc.
> I thought JP re-opened the last call until the 21st because the
changes
> between -05 and -07 were very significant? Here's the message:
> 
> > Since some of changes took place at the very last minute, I would
like
> > to start another WG Last Call on the revision 07 of
> > draft-ietf-roll-of0 that end on March 21 at noon ET. Please send
your
> comments to the Author and copy the mailing list.
> >
> > Thanks.
> >
> > JP.
> 
> Phil

---

From: Philip Levis <[email-masked]>
Date: Wed, 23 Mar 2011 10:34:15 -0700

> http://www.xtranormal.com/watch/7011357/

OK, can you pick up the on the comments I made? 

Phil