Subject: Re: [Roll] Local repair

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Feb 2011 16:24:33 +0100

Hi Ulrich:

This is probably too late to change that text. I think it will be useful
to write informational docs describing some proposed behaviors, and
produce best practices.

With RPL, though, and as Phil explained, you have liberty to take risks
to recover faster, since the risk is later alleviated by the datapath
detection. 

Poisoning and waiting as you proposed is a good recommendation in
classical networks and that's how (E)IGRP operate. So your suggestion
was certainly not irrelevant.

Cheers,

Pascal

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

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ulrich Herberg
Sent: Friday, January 28, 2011 6:40 PM
To: Philip Levis
Cc: roll WG
Subject: Re: [Roll] Local repair

Phil,

On Fri, Jan 28, 2011 at 6:21 PM, Philip Levis <[email-masked]>
wrote:

	Could you please send me a reference?

http://sing.stanford.edu/gnawali/ctp/

and the paper:

http://sing.stanford.edu/gnawali/ctp/sensys09-ctp.pdf

Thanks.

		Yes, I assumed that. I had spoken with a colleague who
is working with the ContikiRPL implementation. They are throwing away
the information about all parents, if a loop between a router and one of
its parents is detected. That's why I asked, but I assume it would be
better to just throw away the one parent where the loop has been
detected.

	This is a terrible idea -- you should instead just mark the
parent's new Rank/Metrics etc. Whether or not the parent is evicted from
the neighbor table should be independent of whether its change is due to
a possible loop. E.g., it could be that the parent is currently looping
through this node, but after loops are repaired this node will need to
route through that neighbor (which chooses a different route).

I agree with you. What I wonder is whether this shouldn't be a bit
explained in the RPL spec (e.g. in sections like "Local Repair
Mechanism" / "Poisoning a sub-DODAG", that explain what an
implementation should do, and what it should not do) . The fact that
implementations do the local repair wrongly, may indicate that it is not
always clear for implementers. 

Ulrich

---

From: Philip Levis <[email-masked]>
Date: Fri, 4 Feb 2011 12:39:59 -0800

On Feb 4, 2011, at 7:24 AM, Pascal Thubert (pthubert) wrote:

> Hi Ulrich:
>  
> This is probably too late to change that text. I think it will be useful to write informational docs describing some proposed behaviors, and produce best practices.
>  
> With RPL, though, and as Phil explained, you have liberty to take risks to recover faster, since the risk is later alleviated by the datapath detection.
>  
> Poisoning and waiting as you proposed is a good recommendation in classical networks and that’s how (E)IGRP operate. So your suggestion was certainly not irrelevant.
>  
> Cheers,
>  
> Pascal

I agree -- I think it's better to keep a specification, well, a specification. It might make sense to have an Informational document giving such advice as a follow-up, but it's important to separate correctness from performance.

Phil

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 4 Feb 2011 15:46:17 -0500

> I agree -- I think it's better to keep a specification, well, a specification. It might make sense to have an Informational document giving such advice as a follow-up, but it's important to separat…

I agree with Phil about having an informational document that deals with implementation or performance improvement related issues as a follow-up document.

John

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

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Ulrich Herberg <[email-masked]>
Date: Sat, 5 Feb 2011 00:05:33 +0100

> On Feb 4, 2011, at 3:39 PM, Philip Levis wrote:
[...]
> I agree with Phil about having an informational document that deals with implementation or performance improvement related issues as a follow-up document.

Yes, I think that we should document such issues; since the RPL draft
is already very long, I am not opposed to having an additional
informal document.

Ulrich

---

From: C Chauvenet <[email-masked]>
Date: Mon, 7 Feb 2011 02:50:16 -0800

+1 for the value of an informal document.

Cédric

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ulrich Herberg
Envoyé : samedi 5 février 2011 00:06
À : JeongGil Ko (John)
Cc : roll WG
Objet : Re: [Roll] Local repair

[...]
> I agree with Phil about having an informational document that deals with implementation or performance improvement related issues as a follow-up document.

Yes, I think that we should document such issues; since the RPL draft is already very long, I am not opposed to having an additional informal document.

Ulrich