Subject: Re: [Roll] New Version Notification for draft-ietf-roll-of0-02

From: "Navneet Agarwal (navagar)" <[email-masked]>
Date: Thu, 22 Jul 2010 09:56:49 +0530

Hi Pascal:
I have the following clarification on OF0-2:

Section-3: The goal of stretching a rank is to allow a node to select
siblings if there is only one parent. Since the sibling has been removed
from the RPL spec, I am not sure the stretch logic of OF-0 is still
applicable...can you pls clarify?

Thx

Regards,
Navneet

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: Wednesday, June 02, 2010 3:19 PM
> To: [email-masked]
> Subject: Re: [Roll] New Version Notification for 
> draft-ietf-roll-of0-02
> 
> Hi:
> 
> OF0-2 was just published. Limited changes include:
> 
> -  make it very clear that only one octet of the rank is 
> really used (from Zigbee's interop comments).
> - provide an abstraction of the interaction with the core 
> spec (requested some time ago on the list) though not at an API level.
> 
> Cheers,
> 
> Pascal
> 
> 
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:[email-masked]]
> > Sent: Wednesday, June 02, 2010 11:44 AM
> > To: Pascal Thubert (pthubert)
> > Subject: New Version Notification for draft-ietf-roll-of0-02
> > 
> > 
> > A new version of I-D, draft-ietf-roll-of0-02.txt has been 
> successfully 
> > submitted by Pascal Thubert and posted to the IETF repository.
> > 
> > Filename:	 draft-ietf-roll-of0
> > Revision:	 02
> > Title:		 RPL Objective Function 0
> > Creation_date:	 2010-06-02
> > WG ID:		 roll
> > Number_of_pages: 9
> > 
> > Abstract:
> > 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 to maximize connectivity.
> > 
> > 
> > 
> > The IETF Secretariat.
> > 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Jul 2010 18:47:24 +0200

Hi Navneet:

The concept of sibling still exists, and at the moment the RPL spec does
not specify how they can be used; in other words they cannot safely be
used. You can thus see the stretch as a filter that filters out
neighbors of low interest because they yield no forward progress. Does
that make sense?

Pascal

> From: Navneet Agarwal (navagar)
> Sent: Thursday, July 22, 2010 6:27 AM
> To: Pascal Thubert (pthubert); [email-masked]
> Subject: RE: [Roll] New Version Notification for
draft-ietf-roll-of0-02
> Section-3: The goal of stretching a rank is to allow a node to select
siblings if
> there is only one parent. Since the sibling has been removed from the
RPL spec,
> I am not sure the stretch logic of OF-0 is still applicable...can you
pls clarify?

---

From: Matteo Paris <[email-masked]>
Date: Thu, 22 Jul 2010 15:19:36 -0400

I think section 10.2.2.3 of rpl-10, "DAO Inconsistency Loop Detection 
and Recovery" could use some clarification.  The first sentence is 
ungrammatical:  "A DAO inconsistency happens when router that has an 
down DAO route via a child that is a remnant from an obsolete state 
that is not matched in the child."  This makes the rest of the 
section difficult to follow.

I believe the intention is to say that a node receiving a 
downward-going packet should check to see if the previous sender is 
its DAO parent.  If not, it notifies the sender by returning the 
packet with the Forwarding-Error 'F' bit set.

If this is the correct interpretation, I believe the entire section 
only applies to the storing mode of operation.  In non-storing mode, 
the packet is source-routed from the root, and no state is maintained 
on the previous upstream hop.  This should be pointed out for clarity.

The second paragraph begins: "In a general manner, a packet that goes 
down should never go up again."  This sounds like a recap of the 
previous section 10.2.2.2, "DAG Inconsistency Loop Detection", which 
explains that the rank must increase when a packet is going downward 
and decrease when a packet is going upward.  I find this sentence 
confusing here because I thought this section was describing a 
*different* kind of inconsistency than the previous section.  Is a 
DAG inconsistency also considered a DAO inconsistency for 
downward-headed packets?  If so, should the corrective actions 
described in 10.2.2.2 (setting the 'R' bit, resetting the Trickle 
timer) be taken in addition to the actions described in 10.2.2.3 
(setting the 'F' bit, etc)?

Thanks,
Matteo

---

From: "Navneet Agarwal (navagar)" <[email-masked]>
Date: Fri, 23 Jul 2010 13:08:45 +0530

Hi Pascal:
Ok

IIUC, the stretch allows you to select additional neighbors (as
siblings) and since they are not to be used at the moment, the stretch
is more of nop. Right?

Thx

Regards,
Navneet 

> From: Pascal Thubert (pthubert) 
> Sent: Thursday, July 22, 2010 10:17 PM
> To: Navneet Agarwal (navagar); [email-masked]'
> The concept of sibling still exists, and at the moment the 
> RPL spec does not specify how they can be used; in other 
> words they cannot safely be used. You can thus see the 
> stretch as a filter that filters out neighbors of low 
> interest because they yield no forward progress. Does that make sense?
> 
> Pascal
> 
> 
> > siblings if there is only one parent. Since the sibling has been 
> > removed from the RPL spec, I am not sure the stretch logic 
> of OF-0 is still applicable...can you pls clarify?
> > 
> > Thx
> > 
> > Regards,
> > Navneet
> > 
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Pascal Thubert (pthubert)
> > > - provide an abstraction of the interaction with the core spec 
> > > (requested some time ago on the list) though not at an API level.
> > >
> > > Cheers,
> > >
> > > Pascal
> > >
> > >
> > > > 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Jul 2010 11:52:19 +0200

Hi Navneet

You're correct. 

The stretch kindof forms clear circles that rationalize the topology;
there's no use for that in the current spec but there are documented
extensions that would benefit from those clear circles. See the concept
of rings in
http://www.ietf.org/mail-archive/web/roll/current/msg03306.html. Also
the concept of beltlines that run an alternate routing within the rings
to bypass the center.

Since it is all mays, I do not see value in removing the stretch text.
You certainly do not have to implement this right now though.

Pascal

> Sent: Friday, July 23, 2010 9:39 AM
> To: Pascal Thubert (pthubert); [email-masked]'
draft-ietf-roll-of0-02
> IIUC, the stretch allows you to select additional neighbors (as
siblings) and since
> they are not to be used at the moment, the stretch is more of nop.
Right?
> > The concept of sibling still exists, and at the moment the RPL spec
> > does not specify how they can be used; in other words they cannot
> > safely be used. You can thus see the stretch as a filter that
filters
> > out neighbors of low interest because they yield no forward
progress.
> > Does that make sense?