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

Geoff,

Just to handle the process question. You are a working group chair so you know how the process works. I am sure you went to the working group chairs' training at Maastricht where we discussed the parameters for adopting working group drafts. (http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF78/IETF78-WGchairs-Adrian-Farrel.ppt)

We have a working group deliverable, and we were asked by the IESG to make sure we deliver this work. The working group needs a place to do its work - a working group draft.

We now have one and the WG can drive the changes as you are doing in the rest of your email.

Thanks for the comments below, the authors will surely address them.

JP.

On Mar 28, 2012, at 12:31 PM, Geoff Mulligan (IETF) wrote:

> 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.
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll