[Roll] AMI applicability: storing/non-storing.

[Michael Richardson <[e-mail]>]

I read draft-ietf-roll-applicability-ami-07 on Monday,and I am so pleased to
see this work resume.  I see that there has been some hard thinking for
certain aspects, and I hope that this process will continue.

Some comments though on storing/non-storing mode.  You write:

>   As a result, different AMI deployments can vary significantly in
>   terms of memory size, computation power and communication
>   capabilities.  For this reason, the use of RPL storing or non-storing
>   mode SHOULD be deployment specific.  When meters are memory

a manufacturer that wishes to make meters for more than one market/RFP would
need to put in enough memory for the worst case storing situation.  So the
advice here is empty. And how many routes is enough?

The restof section 9.1.2 says, "if you have memory use storing mode, if you
don't, then don't".

>   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.

I'm really unclear what this means. What mechanism are you referring?
Route aggregation in BGP4 is accomplished by applocating aggregatable
addresses.   Are you suggesting that all the meters in a high-density
environment should be numbered in a /64 different from the meters in the next
building?   How would this be configured?  What device would do this?

It seems to me that the AMI community would be interested in the hydrid modes
which have been proposed, and further R&D in that area would be waranted.

(The lack of a compromise between storing and non-storing is why I felt that
would perhaps be multiple applicability statements for urban and
suburban/rural environments, and perhaps also for battery operated
environments.  Your 1.3 seems to copy my text exactly, so please edit it.
I would suggest that you write a document that says something like:
  this applies to metering applications where the number of possible parents
  is > X.

(possible parents controls for differences in radio power, propogation, and
physical density of meters. Or you could be specific about radio type,
and just list meter density directly)

--
Michael Richardson <[e-mail]>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/