Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-05.txt

peter van der Stok <stokcons@xs4all.nl> Tue, 04 November 2014 09:46 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5E1A8935 for <roll@ietfa.amsl.com>; Tue, 4 Nov 2014 01:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-86esswq6nJ for <roll@ietfa.amsl.com>; Tue, 4 Nov 2014 01:46:11 -0800 (PST)
Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFD81A8934 for <roll@ietf.org>; Tue, 4 Nov 2014 01:46:11 -0800 (PST)
Received: from roundcube.xs4all.nl ([194.109.20.209]) by smtp-cloud3.xs4all.net with ESMTP id BMm91p00B4WfiVN01Mm9vQ; Tue, 04 Nov 2014 10:46:09 +0100
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 04 Nov 2014 10:46:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 04 Nov 2014 10:46:09 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: Yvonne-Anne Pignolet <yvonne-anne.pignolet@ch.abb.com>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <3dc940374515412880bd6f8123508e7e@DB4PR06MB047.eurprd06.prod.outlook.com>
References: <3dc940374515412880bd6f8123508e7e@DB4PR06MB047.eurprd06.prod.outlook.com>
Message-ID: <c56c3cb742a6e75c618e631c05b541fa@xs4all.nl>
X-Sender: stokcons@xs4all.nl (RSJ0w7rr8nakjHF2yWZyilNoqJzEsW5e)
User-Agent: XS4ALL Webmail
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/WvMX0Twk2A3Klpkl5EGLk2F9YSk
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-applicability-home-building-05.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, 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, 04 Nov 2014 09:46:14 -0000

HI Yvonne,

thank you for your interest and your detailed suggestions.
A subset is answered below.
Possibly one of my co-authors wants to correct or improve my answers.

Peter

Yvonne-Anne Pignolet schreef op 2014-10-21 19:23:
> Dear Anders, Emmanuel, Robert, Peter
> 
> Thanks for the updated draft. I have a few questions and comments and
> would like your feedback as well as opinion from the mailing list.
> 
> 1. In 2.2.7. The authors argue that P2P-RPL is required for P2P and
> P2MP traffic in home and building automation LLNs instead of basic
> RPL.
> 
> I fully agree that P2P-RPL is used for P2P traffic, but for P2MP
> traffic it often makes sense to use basic LLN, also in home and
> building automation LLNs. I suggest to include both P2P-RPL and basic
> RPL in the recommended protocol portfolio for home and building
> automation.

I think we did in section 2.2.7 first phrase, where we mention that RPL 
is useful in the context of the SS paradigm where multiple
servers send data to a central client which may be situated on a 
backbone.

We reserve P2P-RPL specifically for P2P and P2MP traffic.

> 
> 2.  (related to 1.) In 4.1.3. The authors consider DAO policy to be
> out of scope. However, if basic RPL is applicable for home and
> building automation scenarios then due to P2MP traffic  from roots
> DAOs are required. As in the industrial applicability statement I thus
> recommend a paragraph such as "Nodes send DAO messages to establish
> downward paths from the root to themselves. DAO messages are not
> acknowledged in networks composed of battery operated field devices in
> order to minimize the power consumption overhead associated with path
> discovery.  If devices in LLNs participate in multiple RPL instances
> and DODAGs, it is highly recommended that both the RPLInstance ID and
> the DODAGID be included in the DAO."  If the mailing list consensus is
> that P2P RPL is to be used only, then this Section should state that
> DAO messages are not sent in this case. In addition a comment on
> P2P-DRO  Acknowledgement (P2P-DRO-ACK) would be helpful

Some text to motivate the out of scope of DAO policy can be added.
For the multiple RPL instances, I prefer to include a reference to other 
texts.
> 
> 3. Please correct 4.1.4. OF0 is not a metric. Did you mean ETX or HC?
> Or another metric from http://tools.ietf.org/html/rfc6551#section-6.1
> ?

Understood, We'll come with a better recommendation
> 
> 4. Please state why a value of DIO max interval of 4.37min (16ms x
> 2^14) is appropriate, it seems like a much smaller value would be
> suitable for this usecase

I don't understand the issue here. When something happens the 16 ms come 
into play. Assuming a limited number of hops, the change propagates 
quite timely.

When nothing happens, sending a reminder every 4 minutes seems quite 
reasonable. (we are discussing propagation of network changes, not user 
commands)

> 
> 5. About Section 6, 2hy would manageability be out of scope for home
> network scenarios? And can you give more detail on what central
> control based on MIBs entails?

I think the whole discussion on how home networks are managed is still 
on going.
And what to manage is also not clear. For example: will the ISP set the 
RPL parameter values in the nodes in my home and acquire statistics on 
packet fragmentation?

In building automation, setting configuration parameters seems necessary 
(for example the MPL parameter values). Some people think this should be 
done via DHCP. So removing the last phrase of section 6 will improve the 
clarity.

Greetings,

Peter


> 
> Regards
> Yvonne-Anne
> 
> Yvonne-Anne Pignolet
> Dr. Sc. ETH Zürich
> ABB Corporate Research
> Segelhofstrasse 1K
> 5400 Baden-Dättwil, Switzerland
> Phone: +41 58 586 86 56
> Mobile: +41 79 766 10 54
> email: yvonne-anne.pignolet@ch.abb.com
> 
> 
> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der 
> Stok
> Sent: Dienstag, 7. Oktober 2014 00:10
> To: roll@ietf.org
> Subject: [Roll] Fwd: I-D Action:
> draft-ietf-roll-applicability-home-building-05.txt
> 
> Dear wg,
> 
> We submitted draft nr 5 of the home building applicability draft.
> Major changes with respect to draft nr 4
> 
>     o  Large editing effort to streamline text
> 
>     o  Rearranged Normative and Informative references
> 
>     o  Replaced RFC2119 terminology by non-normative terminology
> 
>     o  Rearranged section 5 to better separate the subjects
> 
>     o  Rearranged text of section 7, 7.1, and 7.2 to agree with the
>        intention of section 7.2 as described in applicability template.
> 
> We consider the draft as done and look forward to the next step: wglc.
> 
> Peter
> 
> -------- Oorspronkelijke bericht --------
> Onderwerp: [Roll] I-D Action:
> draft-ietf-roll-applicability-home-building-05.txt
> Datum: 2014-10-06 09:43
> Afzender: internet-drafts@ietf.org
> Ontvanger: i-d-announce@ietf.org
> Kopie: roll@ietf.org
> Antwoord-aan: Routing Over Low power and Lossy networks <roll@ietf.org>
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>   This draft is a work item of the Routing Over Low power and Lossy
> networks Working Group of the IETF.
> 
>          Title           : Applicability Statement: The use of the RPL
> protocol suite in Home Automation and Building Control
>          Authors         : Anders Brandt
>                            Emmanuel Baccelli
>                            Robert Cragie
>                            Peter van der Stok
> 	Filename        : draft-ietf-roll-applicability-home-building-05.txt
> 	Pages           : 30
> 	Date            : 2014-10-06
> 
> Abstract:
>     The purpose of this document is to provide guidance in the 
> selection
>     and use of protocols from the RPL protocol suite to implement the
>     features required for control in building and home environments.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-05
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll