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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 07 August 2013 19:43 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 65BE121E8098 for <roll@ietfa.amsl.com>; Wed, 7 Aug 2013 12:43:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.23
X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, J_CHICKENPOX_63=0.6]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OZTbW8uOnUrw for <roll@ietfa.amsl.com>; Wed, 7 Aug 2013 12:42:56 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCEE21E8092 for <roll@ietf.org>; Wed, 7 Aug 2013 12:42:55 -0700 (PDT)
Received: from sandelman.ca (desk.marajade.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id 38CCD2025B; Wed, 7 Aug 2013 16:49:16 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 243DEA904C; Wed, 7 Aug 2013 15:41:15 -0400 (EDT)
Received: from sandelman.ca (localhost []) by sandelman.ca (Postfix) with ESMTP id 1435CB8EA6; Wed, 7 Aug 2013 15:41:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Wed, 07 Aug 2013 15:41:15 -0400
Message-ID: <23764.1375904475@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: draft-ietf-roll-applicability-ami@tools.ietf.org
Subject: [Roll] AMI applicability: storing/non-storing.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2013 19:43:00 -0000

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/