Subject: [Roll] I-D Action:draft-iwao-roll-dadr-00.txt Comments

From: [email-masked]
Date: Thu, 16 Jul 2009 14:34:47 -0500

Following are comments on the  I-D Action:draft-iwao-roll-dadr-00.txt.   I 
realize you just sent out a new version Tuesday.  I will read that version 
in the next few days.  However, I wanted to get my comments out to the 
ROLL ML.

First, to set perspective, I authored the ROLL Building Requirement ID 
last year; hence, my comments are slanted toward the commercial building 
space requirements.  As the document notes, we have no more than a few 
hundred devices in the LLN with a high level of sensor-to-controller, or 
controller-to-controller messaging.  Event based messages such as alarms 
will be MP2P based.  Every message must be application acknowledged to 
assure it has been properly delivered.  This therefore requires 
bidirectional communication.  All messages are timed out and hence long 
convergence times to repair floating DAGs could be problematic.

We also need to discover devices and objects on-line by using broadcast 
(or multicast) services.  There was really no detail in the ID about how 
multicast would operate on the LNN and the DAG.  Installation methods 
require that all nodes use auto configuration policies hence the IPv6 
prefix will be zeros and therefore not usable for routing discrimination.

That said, my gut tells me that the approach described in the 00 version 
of the draft is not yet suitable for commercial building traffic flow. 
While there is a need for sensors and controllers to move important event 
data to the higher layers, by far most of the control is performed at the 
room or equipment room level and will not be migrated north.  I realize 
the DT noted that P2P communication was not included in the 1st draft and 
am anxiously awaiting the new and improved version.

My detailed comments are below:

p5: DAGID

"This knowledge is used to identify peer nodes ..."  - The word 'peer' is 
confusing here since it might be considered only nodes at the same DAG 
layer.  I believe the meaning meant to be conveyed was all members of the 
DAG.  Maybe 'member' nodes would be more clearly understood.

p5: DAG Sibling

nit - 'node node'  typo should be 'node'

p6: para7

nit -  "Note that in this document, the terms `node' and `LLN router' are 
used interchangeably".  There are no references to 'LLN Router' in the ID. 
 There are many references to 'LLN Node'.  You may want to change the text 
to read  "Note that in this document, the terms `node' and `LLN node' are 
used interchangeably".

p7: section 3.2.2

"The use of multiple paths include sending duplicated traffic along 
diverse paths" - while noted here, I saw no mentioned of duplicating 
packets across multiple paths anywhere within the draft.

p9: para 3

nit - 'As nodes join the DAG they are able advertise...'  should be  'As 
nodes join the DAG they are able to advertise...'

p9: para 4

nit - '...is greedy and tries to pick to many DAG parents' should be 
'...is greedy and tries to pick too many DAG parents'

p13:section 3.3.1.4

nit - 'Note that in such a case traffic may directed along the appropriate 
constrained ...' should be 'Note that in such a case traffic may be 
directed along the appropriately constrained ...'

p17:para 8

 "Destination Advertisement Options to a subset of their DAG Parents"   - 
What defines 'subset'.  Is this a 1-hop multicast to neighbor nodes?  As 
drafted it sounds like the device randomly selects so paths. This seems 
completely nondeterministic.

nit - perios (.) missing at end of paragraph.

p19: section 3.3.4.1

"Such a change would require node (56) to detach from the DAG, to defer 
reattachment until a loop avoidance algorithm has completed ..." Detaching 
and reattaching at a lower layer of the DAG seems to leave communication 
to the LBR nondeterministic with regard to latency.  When a node detaches, 
it must wait its timeout and a RA from a higher layer before it can 
reattach.  The higher layers may not even detect the disturbance and not 
proactively reset their trickle timers.  This could leave a large part of 
the DAG ungrounded for an inordinate amount of time.  In a real-time 
system pertinent life-safety alarms could be unable to be migrated 
northbound for far too long.

nit - '...as it's DAG parents'  should be 'as its DAG parents'

nit - 'There is then little change ...' should be 'There is then little 
chance...'

p23: section 3.4.1

"Although implementation specific, it is worth noting that a node may 
decide to implement some local routing decision based on some metrics..."  
The interoperability requirement is very strong inside commercial 
buildings since the equipment is provided by a bevy of manufacturers. 
Allowing each manufacturer to select its own metric will lead minimally to 
suboptimal routing paths and more like to orthogonal operation that may 
not allow even a single path to be established across nodes.  I understand 
that the IETF typically leaves routing algorithms to the manufacturers. In 
this case I believe the IETF must be more prescriptive since the routers 
are not stand-alone infrastructure devices (Cisco, Alcatel-Lucent), but 
instead HVAC, lighting and fire controllers developed by application 
manufacturers that happen to also do routing as a sideline activity.

'These decisions may be local and/or temporary with the objective to 
maintain the DAG shape while preserving routing stability.' - herein lies 
what I believe is a philosophical problem (which I alluded to in the 
previous paragraph) that runs pervasively across this ID.  Unlike many (or 
all) the protocols supported in the IETF where routers are a special breed 
of devices distinguished from hosts; in an LLN the hosts typically have a 
primary function (control the room temperature) and happen to do routing 
as a secondary task.  As a manufacturer, I want to spend as little time as 
possible worrying about 'maintaining the DAG shape' and more time solving 
building control issues. 

p24: section 4

nit - 'This aim of this section ...' s/b 'The aim of this section ...'

p25: para 4

nit - 'in as antagonistic'  s/b 'in an antagonistic'

p28: DIOIntervalDoublings

nit - 'should be send'  s/b 'should be sent'

p29: DAGID

nit - 'identify'  s/b 'identifies'

p32:para 1

nit - 'an node MAY decide' s/b 'a node MAY decide'  (NOTE: There are many 
occurrences of this nit throughout the spec).

p35:last para

nit - ' One of these information, ' s/b  'One attribute,'

p36:para 3

nit "it's" s/b "its"
nit "looses" s/b "loses"

p36:para 4

nit "it's" s/b "its"

p36:#5

"Nodes MUST ignore RAs that are received from other routers located deeper 
within the same DAG".

The above sentence and actually all of paragraph 5 is confusing.  It reads 
that a node at any lay 'i' must ignore all RAs from all layers 'i+n'. 
However, earlier there was a discussion about how a node must first leave 
the DAG if it wants to move to a lower layer.  How would a node ever 
decide it might want to connect at a lower layer if it must ignore all RAs 
from lower layers?  Furthermore a node may want to reconnect at a lower 
layer of the DAG for application reasons.  That is a room temperature 
sensor would ideally like to be as close as possible in the DAG hierarchy 
to is associated room controller.  Hence the DAG composition should be 
malleable to meet the application layer requirements as well as the 
routing requirements.

p37:#7

"If a node has selected a new set of DAG parents but has not moved yet 
(because it is waiting for DAG Hop timer to elapse), the node is unstable 
and refrains from sending Router Advertisement"

If a node is simply awaiting the timeout of a hop timer before it starts 
its move, it is not yet unstable.  Why would it cease its RAs?  I can 
believe that once it has gone ungrounded it is unstable and may want to 
prohibit RAs, but not before it moves.

p37:#8

"If the node was the last DAG parent then the node SHOULD follow that 
parent."

If for some reason my last DAG parent decides to secede from the DAG and 
hence I have no path to the LBR, I certainly want to pull the plug from my 
radical parent and find a new parent that is still grounded.  Why should I 
have to stay?

p38:para 3

"...use a specific visitor-counter suboption in the DIO."

I don't see the visitor-counter suboption defined in the DIO subheader 
section.

p38:Section 5.4.2

i) 'For instance,  a node that has limited battery..."

How does a sleeping device operate within the DAG since it's not awake to 
get RA, DIO and DAO solicitations?

ii) 'In particular, a node might expose a depth which is incremented by 
more than one from its deepest DAG parent's depth'

While this could be done, I see no utility in doing it.  You mention that 
it can be done 'in order to fit in its own administrative range'.  I don't 
get this.  I don't think layer definition can be defined apriori since the 
number of DAG layers is highly dependent on the job radio configuration. 
Please explain.

p40:Section 5.4.3.3

'In order to detect the situation, LLN Nodes time stamp the sending of 
Router Advertisement' 

The use of time stamps indicate at a minimum clock synchronization 
requirements of the LLN.  It may also be setting a real-time clock 
requirement on the nodes.  Neither of these are acceptable requirements to 
be placed on sensor class devices.

p40:Last para

'...the node with lowest extended preference processes the Router 
Advertisement'

Can you reference where we can find out about 'lowest extended 
preference'?  This term seems to be an external reference.

p42: sect 5.5

I am very concerned about the approach defined for referencing nodes down 
the DAG.  The approach described seems very ad hoc and optional. If Node A 
want to communicate to Node B (even if it's within radio range), it must 
traverse up the DAG until it finds a 'helper' node that will supply the 
path back down the DAG to the destination.  I suspect that in WSNs inward 
DAG nodes will not provide these links unless they themselves 
coincidentally need to talk to the same node.  There's just no RAM 
available for these nodes to build expansive router tables to nodes that 
one-day might need to be traversed.

That said, it is highly likely that the packet will ascend up the DAG all 
the way to the LBR.  However, there is no mandate that even the LBR has 
connectivity to all subservient nodes.  So it's quite possible that there 
is no connectivity defined in the DAG for Node A to talk to Node B even 
though there is ample radio coverage to access the node.  It is highly 
undesirable for a packet to traverse through many DAG layers when it might 
be able to pass the packet P2P or a single hop.  It is unacceptable if 
there are nodes that simply can't be accessed at all because of the 
defined DAG map.

p42:

As noted above that it's possible that some nodes may have no 
communication to other nodes, I wonder how multicasts will work on the 
DAG.  I support multicasts may not be in the province of the DAG and hence 
has some orthogonal solution.  However, the ID should clearly state 
whether the DAG map is used to forward multicast packets across the entire 
LLN.

p44: DAO Depth

DAO Depth is set to 0 rather than the relative DAG layer address of the 
node.  Why would that be?  I would think we would want all references 
within the DAG to be based on the relative position of the node within the 
DAG..

p44:Prefix

My read of the 6LoWPAN ID indicated that for 6LoWPAN devices using 
auto-configuration, the prefix was simply the PAN ID and 53 trailing 
zeros.  This seems to indicate that the prefix is carrying much more 
topological information.

p44:5.5.2.1

The DAO algorithm as previously noted seems unreliable since it can't 
guarantee connectivity to all nodes within the DAG.  Reading this section 
further concerns me that we need to consider data queries from outside the 
LNN through the LBR onto the DAG.  That is the data flow through the LBR 
is bidirectional not unidirectional.

p45:para4

nit - 'A no-DAO is a conveyed' s/b 'A no-DAO is conveyed'

p46:para 2

In this way the Reverse Route Stack will come to contain a vector of next 
hops that must be traversed along the reverse path that the DAO has 
traveled.

This sentence implies that the metrics used to defined the inward 
(northbound) DAG structure can be used to deliver outbound (southbound) 
DAG messages.  Empirical tests show this is not true.  A high percentage 
of our paths (upwards to 70%) are asymmetrical.  That is the Node A to 
Node B path is not the same as the Node B to Node A path.  Assuming we can 
use the DAG paths defined for inbound traffic successfully for outbound 
traffic may be erroneous.