[Roll] Comments on draft-ietf-roll-applicability-ami-05

["Geoff Mulligan (IETF)" <[e-mail]>]

First, I do not understand why this document is not still draft-popa 
rather than being a working group document.  It was never adequately 
explained how this draft went from being submitted to becoming a working 
group document in just a few hours with absolutely no discussion on the 
Roll mailing list.  While that might be allowed it certainly is not in 
the spirit of IETF process.

So, away from process and to the draft itself...

In the first paragraph of section 1.3:
Current text: RPL provides routing functionality for mesh networks that 
can scale up to thousands of devices...

New text: RPL provides routing functionality for mesh networks that 
might be able to scale up to thousands of devices...

Alternate new text: RPL provides routing functionality for mesh networks 
that hopefully will be shown to scale up to thousands of devices...

On the same page:
Current text: RPL was designed to meeting the requirements of Building 
Automation.

New text: RPL was designed to meeting the requirements of Building 
Automation, but does not currently meet these requirements

In section 2.1.1...
Current text: ... the nearest LBR may be composed of several hops or 
even several tens of hops.

New text: ... the nearest LBR may be composed of several hops or even 
several tens of hops. While RPL has been shown to work over 1 or 2 hops, 
it will hopefully be shown to work over tens of hops.

Section 2.2.1...
The fourth paragraph states that SMD traffic is highly asymmetric.  
While for meter data this may be true for traffic volume, but it should 
be noted that for number of packets this is probably not the case when 
packet ACKs are taken into account.

Also since this is a draft about AMI, it is not correct to extrapolate 
meter data to a full AMI deployment where much more data and packets 
will be sent to the home and the data and packets may be nearly symmetric.

It should be pointed out that while RPL appears to support MP2P pretty 
well, it is unclear how well RPL will be able to support P2MP or P2P on 
a large scale as required in potential AMI networks.

Current text: Current SMD traffic patterns are fairly uniform and 
well-understood. The traffic generated by the head-end server and 
destined to metering devices is dominated by periodic meter reads, while 
traffic generated by the metering devices is typically uniformly spread 
over some periodic read time-window.

New Text: While current SMD traffic patterns are fairly uniform and 
well-understood, the traffic patterns for AMI deployments is not yet 
well-understood.  For SMD, the traffic generated by the head-end server 
and destined to metering devices is dominated by periodic meter reads, 
while traffic generated by the metering devices is typically uniformly 
spread over some periodic read time-window, whereas in future AMI 
deployments traffic may not be dominated by just meter reading and may 
instead be dominated by command/control messaging and may not be 
uniformly spread over a time-window.

Current text: From a routing perspective, SMD applications require 
efficient P2MP communication between the devices in the network and one 
or more LBRs.

New text: From a routing perspective, while SMD applications require 
efficient MP2P communication between the devices in the network and one 
or more LBRs, AMI networks will likely require efficient P2MP and P2P 
communications.

Section 2.2.2 DA comms
This section  defines some requirements for DA and it is implied that 
RPL meets these requirements, but it does not that it does or how it 
does.  RPL has not been shown to meet these requirements, but it appears 
the draft would like the reader to assume that RPL does.

Section 4.1.2
This paragraph:
When meters are memory constrained and cannot adequately store the route 
tables necessary to support hop-by-hop routing, RPL non-storing mode 
SHOULD be preferred. On the other hand, when nodes are capable of 
storing such routing tables, the use of storing mode may lead to reduced 
overhead and route repair latency. However, in high-density 
environments, storing routes can be challenging because some nodes may 
have to maintain routing information for a large number of descendents. 
When the routing table size becomes challenging, it is RECOMMENDED that 
nodes perform route aggregation, similarly to the approach taken by 
other routing protocols, although the required set of mechanism may differ.

This paragraph fails to warn the reader of the problems associated with 
storing vs. non-storing mode and implies that all this is solved.  It 
needs to be expanded to explain the trade-offs of band-width, packets 
sizes, contention vs memory requirements and it is not a simple if you 
don't have enough memory, just use non-storing mode or just use route 
aggregation which is not yet a solved problem in RPL.

Section 4.1.3
Current text:
Two-way communication is a requirement in AMI systems. As a result, 
nodes SHOULD send DAO messages to establish downward paths from the root 
to themselves.

Is this a MUST?

Section 4.1.5
Current text:
Two objective functions for RPL have been defined at the time of this 
writing, OF0 and MRHOF, both of which define the selection of a 
preferred parent and backup parents, and are suitable for AMI deployments.

New text:
Two objective functions for RPL have been defined at the time of this 
writing, OF0 and MRHOF, both of which define the selection of a 
preferred parent and backup parents, and either may be suitable for AMI 
deployments.

Section 4.1.6
Current text:
While detached, a node advertises an infinite rank value so that its 
children can select a different parent.

New text:
While detached, a node advertises an infinite rank value so that its 
children can select a different parent. During this time the entire sub 
DODAG is unstable and does not have connectivity to the LBR or the rest 
of the network.

Current text:
Setting the DAGMaxRankIncrease to a non-zero value enables this 
mechanism, and setting it to a value of less than infinity limits the 
cost of count-to-infinity scenarios when they occur, thus controlling 
the duration of disconnection applications may experience.

Some numbers would be helpful.  What numbers provide what durations.

Section 4.1.7
Current text:
Multicast support for RPL in non-storing mode will be defined in 
companion RFCs.

New text:
Multicast support for RPL in non-storing mode will be defined in 
companion RFCs, so therefore multicast for large networks with memory 
constrained devices is not yet supported or defined.

Section 4.1.8
Current text:
AMI deployments operate in areas that do not provide any physical 
security. For this reason, the link layer, transport layer and 
application layer technologies utilized within AMI networks typically 
provide security mechanisms to ensure authentication, confidentiality, 
integrity, and freshness. As a result, AMI deployments may not need to 
implement RPL's security mechanisms and could rely on link layer and 
higher layer security features.

New text:
AMI deployments operate in areas that do not provide any physical 
security. For this reason, the link layer, transport layer and 
application layer technologies utilized within AMI networks typically 
provide security mechanisms to ensure authentication, confidentiality, 
integrity, and freshness of the AMI data but not the authentication, 
integrity or freshness of the routing control information. As a result, 
AMI deployments SHOULD implement RPL's security mechanisms and cannot 
rely on link layer and higher layer security features.

Section 4.2.1
Current text:
In high density environments, relatively low values for Imin may cause a 
short period of congestion when an inconsistency is detected and DIO 
updates are sent by a large number of neighboring nodes nearly 
simultaneously. While the Trickle timer will exponentially backoff, some 
time may elapse before the congestion subsides.

It would be good to nail down some values.  What is a "relatively low 
value" that will result in what kind of short period of congestion.  
What is "some time"? What orders of magnitude? Seconds, minutes, 
micro-seconds...

DIOIntervalMin: This paragraph recommends a value - GREAT, but what is 
the result of this choice?  What happens if you choose a number greater 
or smaller?

DIOIntervalDoublings: Same comment - what if I choose a different 
value?  What is the result?  What is the result in performance if I 
choose either of these values.

Section 4.2.2
Current text:
AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 8 
bits of resolution (e.g., for the ETX metric).

What are the results of choosing 256.  Why 256 and not 128 or 512 or any 
other number.

Current text:
To enable local repair, AMI deployments SHOULD set MaxRankIncrease to a 
value that allows a device to move a small number of hops away from the 
root. With a MinHopRankIncrease of 256, a MaxRankIncrease of 1024 would 
allow a device to move up to 4 hops away.

What is the result of choosing 256.  How did you arrive at this number.  
What is performance trade-off?  Is this based on some specific 
bandwidth, number of nodes in the network, depth of the network, ...

Section 6
Current text:
As a result link-layer, transport-layer and/or application-layer 
security mechanisms are typically in place and using RPL's secure mode 
is not necessary.

Same comment as the previous section on security.