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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 05 November 2013 21:50 UTC

Return-Path: <mcr@sandelman.ca>
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 61ADD21F9FBE for <roll@ietfa.amsl.com>; Tue, 5 Nov 2013 13:50:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 gNt5E73IwXOe for <roll@ietfa.amsl.com>; Tue, 5 Nov 2013 13:50:27 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 494A221F9F99 for <roll@ietf.org>; Tue, 5 Nov 2013 13:50:27 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A0A02026C for <roll@ietf.org>; Tue, 5 Nov 2013 18:02:04 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 219D463B88; Tue, 5 Nov 2013 16:50:21 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0FE1D63AED for <roll@ietf.org>; Tue, 5 Nov 2013 16:50:21 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <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> <6da51339f73145878551c75ae2d794a9@DBXPR01MB015.eurprd01.prod.exchangelabs.com>
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: Tue, 05 Nov 2013 16:50:21 -0500
Message-ID: <12227.1383688221@sandelman.ca>
Sender: mcr@sandelman.ca
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 21:50:28 -0000

Turner, Randy <Randy.Turner@landisgyr.com> wrote:
    > 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. 

Yes there could be, but it needs more research.  
There was at least one ID in the past year discussion how this could be
supported.   

The problem is not generally deep in the DODAG, as the fan out
means that there are few children, thus they fit into ram.  The problem is
closer to the top, where there are more children than fit.

There was significant discussion on the list and at meetings a few years ago;
look 6 months before the publication date of 6550.  
As I recall, one can not just keep some routes and not others due to how
parents might change.

-- 
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/