Re: [6tisch] Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice

Ralph Droms <> Tue, 31 January 2017 12:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2C9F129E37; Tue, 31 Jan 2017 04:04:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lQvdlpu45bVw; Tue, 31 Jan 2017 04:04:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDB1C129E3A; Tue, 31 Jan 2017 04:04:22 -0800 (PST)
Received: by with SMTP id n13so59488246qtc.0; Tue, 31 Jan 2017 04:04:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ROBIvX3BVqijRz3WgRcPy0hetrzR1W9J4M+mfnZAUF4=; b=U9ka9fS8yylGWpypkwq/pLtt8r992tJG/hsAY3BoQ+j5GTkb2tALock+q5jbT8zmjc GL7vwDsO6CeM0sclfDKNGDKOibnrdMnY4Czm8ObwDpOS470U6r9Pu9oKXAJ3tljQvXhk /a1guvxTXIw28oo61t8q65AVEhJlK/2gWYVKBzqPp8dRlO+RfA0AuY64vSHd7q2PPCZT +x36fGrz/CY6a6oFeaGvAlaTjXhiJZS/B+zz/QfiFYTUDHSLAXbxUIkIWIa2y9TrzJYe 6ACa3/l4tWVWpmOSiah+8R80UF7h6AthXKr8a4bVqzCeZkFDctnvZegs9xSZbzWP9qdR 5NUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ROBIvX3BVqijRz3WgRcPy0hetrzR1W9J4M+mfnZAUF4=; b=mai1xSOHeTD6zUqCiWVjcCr7iuIBmev/0fXEgW/U1hL6qT+9+gkyytpyvsiRrzW8l8 0XeOq78tMdePPHBJBDVXR+1IasOLb+UsH1JW40CTVs48ao8eZ0vDNL3bLzrJ2eT+f1pG Q4ZHYnY0krSe6/LYyQi1PjJXC8VmjRExQUdcnTV6DABcYEnVeFfi2gp+wY0u3iW9bFP9 d7O440WQZe9Zn33wKtpCwfTAFLt2zFctA3Q+te1vSjY/gLt7/Dy08b1PS6NEanpMuGMk IM2DRyhzd1eP0es4U7f+GLxvt2/N8PtRH8XI6DMBQyU5/aCdI0FOQ4HUJUAk9+m8LLwT u0Cg==
X-Gm-Message-State: AIkVDXKbp46K8wAgoUg5Szy8Fn1IKQQLH7VrWF8zPP77idLVl/FIaSFzgWhKCjvrS0Y3RA==
X-Received: by with SMTP id t15mr25998109qtt.84.1485864262162; Tue, 31 Jan 2017 04:04:22 -0800 (PST)
Received: from ?IPv6:2601:18f:801:600:85d3:a4fe:5e55:a31c? ([2601:18f:801:600:85d3:a4fe:5e55:a31c]) by with ESMTPSA id w138sm15066536qka.27.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 04:04:21 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-BAE03D24-5128-43BB-8AE2-9A1B2C35B8D0
Mime-Version: 1.0 (1.0)
Subject: Re: [6tisch] Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice
From: Ralph Droms <>
X-Mailer: iPad Mail (14C92)
In-Reply-To: <>
Date: Tue, 31 Jan 2017 07:04:20 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <> <> <>
To: Xavi Vilajosana Guillen <>
Archived-At: <>
Cc:, 6tisch <>,, IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jan 2017 12:04:25 -0000

> On Jan 31, 2017, at 2:21 AM, Xavi Vilajosana Guillen <> wrote:
> Dear Ralph,
> thanks for your comments. Let me answer inline some of your questions:
> 2017-01-30 17:56 GMT+01:00 Ralph Droms <>:
>> I've reviewed draft-ietf-6tisch-minimal-19.  Thank you to the authors and the WG for considering the input from my earlier reviews and careful revision of the document to address that input.
>> In general, I think the document is now almost ready for publication.  The major points from my review of -17 have been addressed.
>> I do have a few minor points for the authors and WG to consider:
>> Does the WG have consensus that IPv6 address selection, prefix advertisement, and the details of ND need not be addressed in this document? 
>> I don't see a default value for EB_PERIOD defined anywhere.  Is such a definition needed?
> The EB_PERIOD determines the join time and impacts energy consumption. The value is a trade-off of this two elements according to the network administrator, as shorter the EB period more energy is used but sooner the nodes join the network. This number does not affect different vendor nodes aiming to join the same network (in terms of inter-operability). For us this is more a network policy, IMHO defining a default value would not fit most of the cases. 

Is it necessary for all devices in a network to use the same value EB_PERIOD? 

If so, how is that value communicated or configured in all devices?

Could the document recommend a value?

>> Section 5.2 requires implementation of RPL non-storing mode and recommends implementation of storing mode.  How does a node know whether RPL is being used in non-storing or storing mode?
> This is detected by the MOP field in the DIO. When a DIO is received the MOP is checked. According to RF6550
>    Mode of Operation (MOP): The Mode of Operation (MOP) field identifies
>          the mode of operation of the RPL Instance as administratively
>          provisioned at and distributed by the DODAG root.  All nodes
>          who join the DODAG must be able to honor the MOP in order to
>          fully participate as a router, or else they must only join as a
>          leaf.  MOP is encoded as in the figure below:

Ah, ok, thanks.

- Ralph

>> - Ralph
> regards,
> Xavi
> -- 
> Dr. Xavier Vilajosana
> Wireless Networks Lab
> Internet Interdisciplinary Institute (IN3)
> Professor
> (+34) 646 633 681
> Parc Mediterrani de la Tecnologia 
> Av Carl Friedrich Gauss 5, B3 Building
> 08860 Castelldefels (Barcelona). Catalonia. Spain