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

"Turner, Randy" <Randy.Turner@landisgyr.com> Tue, 05 November 2013 18:59 UTC

Return-Path: <Randy.Turner@landisgyr.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454D521E812E for <roll@ietfa.amsl.com>; Tue, 5 Nov 2013 10:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul2OdsilWFmE for <roll@ietfa.amsl.com>; Tue, 5 Nov 2013 10:59:17 -0800 (PST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0077.outbound.protection.outlook.com [213.199.154.77]) by ietfa.amsl.com (Postfix) with ESMTP id 34E9721E8085 for <roll@ietf.org>; Tue, 5 Nov 2013 10:59:13 -0800 (PST)
Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com (10.255.176.37) by DBXPR01MB016.eurprd01.prod.exchangelabs.com (10.255.176.38) with Microsoft SMTP Server (TLS) id 15.0.815.6; Tue, 5 Nov 2013 18:59:10 +0000
Received: from DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.119]) by DBXPR01MB015.eurprd01.prod.exchangelabs.com ([169.254.12.119]) with mapi id 15.00.0815.000; Tue, 5 Nov 2013 18:59:10 +0000
From: "Turner, Randy" <Randy.Turner@landisgyr.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] AMI applicability: storing/non-storing.
Thread-Index: AQHO2aeOElTiGDu4skinht2fNlWkvJoWaBGAgACUR4CAAAFZMA==
Date: Tue, 05 Nov 2013 18:59:09 +0000
Message-ID: <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com>
References: <23764.1375904475 at sandelman.ca> <13540.1383601637@sandelman.ca> <4c8f248d750f480baaf5f2a4dde71621@CO1PR04MB346.namprd04.prod.outlook.com> <7933.1383677399@sandelman.ca>
In-Reply-To: <7933.1383677399@sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [148.80.255.144]
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(13464003)(24454002)(377454003)(189002)(199002)(19580405001)(83322001)(54316002)(74876001)(19580395003)(80976001)(74706001)(50986001)(46102001)(83072001)(2656002)(51856001)(74316001)(53806001)(56816003)(81686001)(54356001)(77096001)(69226001)(81816001)(81342001)(80022001)(66066001)(59766001)(65816001)(76786001)(76796001)(85306002)(76482001)(87266001)(47976001)(47736001)(49866001)(56776001)(81542001)(33646001)(47446002)(15202345003)(15975445006)(4396001)(74502001)(31966008)(74366001)(77982001)(63696002)(79102001)(74662001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR01MB016; H:DBXPR01MB015.eurprd01.prod.exchangelabs.com; CLIP:148.80.255.144; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: landisgyr.com
Subject: Re: [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: Tue, 05 Nov 2013 18:59:22 -0000

I agree that non-storing mode addresses the primary AMI use-case where endpoints push data up and through the DODAG root.

Could there be a "hybrid-storing" mode that doesn't use as much RAM to contain routes to all nodes in a sub-tree? Instead of traditional storing mode, could a node store just multicast memberships in all nodes "below" a particular mote ?  Assuming there would much fewer multicast memberships than would be required for RFC 6550 storing mode ?  It's a variant of storing+multicast, without the traditional storing mode RAM usage.

I'm still looking at the MPL document, so apologies if that's already discussed.

Randy

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson
Sent: Tuesday, November 05, 2013 1:50 PM
To: Routing Over Low power and Lossy networks
Subject: Re: [Roll] AMI applicability: storing/non-storing.


Popa, Daniel <Daniel.Popa@itron.com> wrote:
    Daniel> However, my point is that these challenges are mostly related to
    Daniel> RPL storing mode of operation. As a consequence, I am OK to
    Daniel> narrow down the scope of the applicability statement for AMI to
    Daniel> only RPL non-storing mode of operation, as I stated in my
    Daniel> previous email. As for having different specs for different use
    Daniel> cases, I expect that by focusing only on RPL non-storing mode a
    Daniel> single AMI applicability statement will be able to cover
    Daniel> efficiently "all" the reasonable requirements, for "all" use
    Daniel> cases.

Ah, I did not understand that from your previous email.
Yes, please.  Pick non-storing, and lets' proceed!!!

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.