Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05

From: JP Vasseur <[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.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Sat, 12 Mar 2011 23:57:32 -0800

Did we decide to stick with the OF0 name? I think there were
suggestions to change it so it reflects better what it is about.

- om_p

On Thu, Mar 10, 2011 at 9:08 AM, JP Vasseur <[email-masked]> wrote:
> 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.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Mar 2011 10:32:05 +0100

Hi Om:

There was and nothing really came out of it. After a discussion with
Phil and Dave, even the term last resort will go away.

Cheers,

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

> -----Original Message-----
> From: Omprakash Gnawali [mailto:[email-masked]]
> Sent: Sunday, March 13, 2011 8:58 AM
> To: JP Vasseur
> Cc: Pascal Thubert (pthubert); ROLL WG
> Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05
> 
suggestions to
> change it so it reflects better what it is about.
> 
> - om_p
> 
> > 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 ?
> > 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.

---

From: JP Vasseur <[email-masked]>
Date: Sun, 13 Mar 2011 10:34:18 +0100

Hi,

> Phil and Dave, even the term last resort will go away.

As a reminder, changes must be discussed with the WG.
JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Mar 2011 10:50:42 +0100

Hi JP and Phil:

The open issue was Phil's comment on the values that in particular
MAXIMUM_RANK_STRETCH would not allow more than 16 worst quality hops,
which could be problematic in certain cases

It has to be noted that:

*         Getting 16 hops in a row of the worst possible quality seems,
like, extreme

*         the large gap between MINIMUM_RANK_INCREMENT and
MAXIMUM_RANK_STRETCH (a factor of 16) allowed to actually making a
distinction between links of different types or categories in order to
strongly favor say powered over battery or wire over wireless within a
same DAG. A reduced range will lower that capability. To compensate that
loss, I'm proposing a new multiplication factor that can be applied by
configuration to distinguish such cases.

So to address the comment, I'll publish with the new proposed value:

   MinHopRankIncrease:  256

   DEFAULT_RANK_INCREMENT:  3 * MinHopRankIncrease

   MINIMUM_RANK_INCREMENT:  1 * MinHopRankIncrease

   MAXIMUM_RANK_INCREMENT:  9 * MinHopRankIncrease

   MAXIMUM_RANK_STRETCH:  5 * MinHopRankIncrease

(NEW) MAXIMUM_RANK_FACTOR: 4

What do you think?

Pascal

From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, March 10, 2011 6:09 PM
To: Pascal Thubert (pthubert)
Cc: ROLL WG
Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05

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

Thanks.

JP.

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.

Thanks.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Mar 2011 11:11:34 +0100

Hi JP:

The discussion about OF0 and wireless appeared on the ML, and you're
right the latest developments should have had continued there.

Basically we (seem to) have a consensus that hop count is not wireless
friendly. We have text about that in OF0.

We also have text in OF0 that says that the step of Rank is/can be
strongly related to hop count, which makes it unfriendly to wireless.
Yet, the step of Rank but can also derive from link metrics, in which
cases depending on how this is done in an implementation, it can be
wireless friendly. 

So the recent addition that OF0 is not wireless friendly was actually
partially my mistake. This assertion is really about hop count and
classical static metrics that directly derive from hop count. This will
be fixed in OF6 as part of that existing discussion.

In that same discussion, I proposed to qualify OF0 of a 'last resort'
OF. What I meant by that is that OF0 is not expected to be the best
possible for a given situation but something that can at least allow
connectivity regardless of about everything. In particular, OF0 is not
specific about how the Rank is computed when it is derived from a link
property, this is fully left to implementation or further guidance.

Rather, OF0 normalizes an additive metric to a 'normal' step of Rank
giving a range from best to worst -note:  this range is what the last
open issue is about - .  Because OF0 is not specific, it will permit
connectivity but not necessarily the expected optimum by a given
implementation when multiple implementations that compute the step of
Rank differently share a network.

I got comments outside the list that last resort is not appropriate. The
proposal here is to reword without the term, better explain the above
while conserving the spirit. 

My proposal is to post 18 before cutoff to the diffs will be visible to
the group before the last issue is solved.

What do you think?

Pascal

> Sent: Sunday, March 13, 2011 10:34 AM
> Cc: Omprakash Gnawali; ROLL WG

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Mar 2011 11:57:54 +0100

All:

Here's more text that goes with the proposed resolutionof the range
issue:

   The gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH may

   not be sufficient in every case to strongly distinguish links of

   different types or categories in order to favor, say, powered over

   battery-operated or wired over wireless, within a same DAG.  An

   implementation SHOULD allow a configurable factor called Rank Factor

   and to apply the factor on all links and peers.  An implementation

   MAY recognizes sub-categories of peers and links, such as different

   MAC types, in which case it SHOULD be able to configure a more

   specific Rank Factor to those categories.  The Rank Factor SHOULD be

   set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR.  Once a step

   of Rank is computed along the rules specified in this document, the

   result of the computation is multipled by the Rank Factor and the

   result is what gets added to the Rank of preferred parent in order to

   obtain the Rank of this node.

also

7.  OF0 Constants and Variables

   OF0 uses the following constants:

   MinHopRankIncrease:  256

   DEFAULT_RANK_FACTOR:  1

   MINIMUM_RANK_FACTOR:  1

   MAXIMUM_RANK_FACTOR:  4

What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: Sunday, March 13, 2011 10:51 AM
To: JP Vasseur; Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05

Hi JP and Phil:

It has to be noted that:

 

   MinHopRankIncrease:  256

 

What do you think?

Pascal

Dear all,

Thanks.

JP.

Dear all,

Thanks.

JP.

---

From: Omprakash Gnawali <[email-masked]>
Date: Sun, 13 Mar 2011 09:31:45 -0700

>> Phil and Dave, even the term last resort will go away.

How about "no metric" rather than "last resort"? That would be an
accurate description of this OF. Why not use a name that describes
this OF rather than OF0, which does not say what it is and makes it
sound like default OF? If the intention is to make it a default OF,
that should be stated explicitly.

- om_p

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 13 Mar 2011 18:56:57 +0100

Hi Om:

It is not really "no metric" BUT "no metric container". An
implementation is free to use any property of the link or the peer and
turn that into a step of rank...
For all I know, MrHof could be seen as an instance of OF0. If that's the
case, maybe you can simplify a bit of your spec by inheriting.

All in all, it is a bit late for the name changing. We're past last
call, focusing on solving the LC issue and pass to IESG.

All the best,

Pascal

> Sent: Sunday, March 13, 2011 5:32 PM
> To: JP Vasseur
accurate
> description of this OF. Why not use a name that describes this OF
rather than
> OF0, which does not say what it is and makes it sound like default OF?
If the
> intention is to make it a default OF, that should be stated
explicitly.

---

From: Philip Levis <[email-masked]>
Date: Sun, 13 Mar 2011 11:14:30 -0700

> call, focusing on solving the LC issue and pass to IESG.

The IESG changes for RPL necessitate some changes. For example, the current text relating to backup next hop is now out of sync with RPL section 14 (and, actually, RPL generally, there's no mention of a parent set, and the rules for the backup next hop in Section 5 contradict DIO processing rules in RPL). These issues were minor when OF0 stated it was not suited to wireless (which, as written, it isn't), but now that the this qualification has been removed there are further issues.

Here's the basic problem: as a working group, our job is to try to standardize and specify standard, well understood practice when at all possible, and only when absolutely necessary discuss and reach consensus on something new. OF0 is taking on a role of being the basic OF that nodes SHOULD support for interoperability (i.e., so that a RPL node can join an OF0 network as a router). There's a huge amount of engineering experience in this space, many different networks and protocols that do something much like RPL.

But *none* of them, as far as I know, do anything like OF0. It's something "new." This seems contrary to the overall goal of the IETF. OF0 is the way it is because you wrote it up early as an idea for how an OF might work. Our criterion for what to standardize on should not be "first out of the gate." It seems like a terrible mistake to me to have RPL specify OF0 -- a routing metric with almost no long-term, practical experience -- as the basic interoperable routing metric when there are others which are well understood.

These issues have to do with the real details of OF0, not its basic ideas, which are sound. But good engineering often deals with details, as the recent discussions over section 14 demonstrate.

Phil

---

From: Philip Levis <[email-masked]>
Date: Sun, 13 Mar 2011 11:23:16 -0700

> be fixed in OF6 as part of that existing discussion.

This is not totally correct. Now some of the processing rules specified in OF0 are out of sync with the processing rules specified in RPL.

E.g.: OF0 says

   o  The backup next_hop MUST be either in the same DODAG version as
      the preferred parent or in an subsequent version.

while RPL says

   o   Every element of a node's DODAG parent
       set, as conveyed by the last heard DIO message from each DODAG
       parent, MUST belong to the same DODAG Version.  

What OF0 is doing is removing the concept of a parent set, which is critical for DAO operation.

OF0 also has text like

   o  A Router with a Rank that is higher than the Rank computed for
      this node out of the preferred parent SHOULD NOT be selected as
      parent, to avoid greedy behaviors.  It MAY still be selected as
      sibling if no better Back-up next hop is found.

Note that RPL has no notion of "siblings:" this abstraction was pulled out many, many versions ago. But the current OF0 text has not kept up, and so it contradicts RPL. 

> the group before the last issue is solved.

Given some of these changes are major, I think posting is the right thing to do. Now that RPL is stable. we should discuss OF0 at 80 and go through one more iteration on it to make sure it is perfectly in sync with the main specification. I am happy to help with this and go through it with a fine-toothed comb. Hopefully we can do this quickly and then move on immediately after 80. But version -06 will be mildly disastrous, now that OF0 *is* supposed to apply to wireless and other LLNs.

Phil

---

From: Omprakash Gnawali <[email-masked]>
Date: Sun, 13 Mar 2011 11:26:47 -0700

> turn that into a step of rank...

Great. You can call it "no metric container" OF then.

> call, focusing on solving the LC issue and pass to IESG.

I had suggested the name change in Feb on ROLL list and my assumption
was you were looking into that. If it is too late, its not a problem.

> case, maybe you can simplify a bit of your spec by inheriting.

I am open to this interpretation. However, the inheritance should be
from the OF section in RPL draft. That section describes in abstract
sense what "OF0" and MRHOF do. It is important for the OF section in
RPL, OF0, and MRHOF are compatible in their descriptions of OF.

In -06, I suggest being more concrete in this text:

"Instead, careful thinking should be applied	
			to determine how the step of Rank is computed from the link	
			properties and attention should be paid to maintain a certain	
			stability in the resulting Rank."

- om_p

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Mar 2011 09:56:34 +0100

Hi Phil:

> > classical static metrics that directly derive from hop count. This
> > will be fixed in OF6 as part of that existing discussion.
> 
> This is not totally correct. Now some of the processing rules
specified in OF0
> are out of sync with the processing rules specified in RPL.

[Pascal] is that related to wireless or a more general comment?

> What OF0 is doing is removing the concept of a parent set, which is
critical for
> DAO operation.

[Pascal] I love the way you reverse logic. The backup next hop is not
necessarily a parent (I would have called it backup parent I suppose).
It is a backup next hop that allows forwarding traffic.  "The backup
next_hop might be a parent or a sibling" does not have ONLY in it. But I
agree I can make that a bit more clear as a simple editorial. Will do
that.

Note: If the backup next hop is from a subsequent version then it is
also ready to be used as a parent when this node moves to that version,
e.g. if the preferred parent in the current version is no more available
or the preferred parent move to the subsequent version. You'll note that
passing a packet to a non-parent backup implies acting as a leaf for the
version of the backup. This is specified in RPL.

> Note that RPL has no notion of "siblings:" this abstraction was pulled
out
> many, many versions ago. But the current OF0 text has not kept up, and
so it
> contradicts RPL.

[Pascal] RPL does not prevent siblings. It just leaves them to further
specification. In particular a new OF is not obliged/encouraged by the
main spec to consider siblings.
But I think I agree with your bottom line. if OF0 is to be referenced by
RPL then this text takes a new importance and should be examined by the
group.

> > I got comments outside the list that last resort is not appropriate.
> > The proposal here is to reword without the term, better explain the
> > above while conserving the spirit.
> >
> > My proposal is to post 18 before cutoff to the diffs will be visible
> > to the group before the last issue is solved.
> >
> > What do you think?
> 
> Given some of these changes are major, I think posting is the right
thing to
> do. Now that RPL is stable. we should discuss OF0 at 80 and go through
one
> more iteration on it to make sure it is perfectly in sync with the
main
> specification. I am happy to help with this and go through it with a
fine-
> toothed comb. Hopefully we can do this quickly and then move on
> immediately after 80. But version -06 will be mildly disastrous, now
that OF0
> *is* supposed to apply to wireless and other LLNs.
> 
[Pascal] Your help is definitely appreciated (even and mostly when we
disagree at the start : ) ).
 I'll post a 7 to clarify your point 1. But I need the group on your
point 2.

Cheers,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Mar 2011 10:01:50 +0100

> I am open to this interpretation. However, the inheritance should be
from
> the OF section in RPL draft. That section describes in abstract sense
what
> "OF0" and MRHOF do. It is important for the OF section in RPL, OF0,
and
> MRHOF are compatible in their descriptions of OF.
> 
> 			to determine how the step of Rank is computed
from
> the link
> 			properties and attention should be paid to
maintain a
> certain

[Pascal] I can hardly add normative text at this point. 
But I suppose that giving a non-normative example that points on Mr Hof
as a way to handle the situation would not hurt.
I'll optimistically post 7 with that and if that's against the rules
after LC then I'll repost to remove.

Pascal