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

Xavi Vilajosana Guillen <> Tue, 31 January 2017 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0997912961F for <>; Mon, 30 Jan 2017 23:22:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2vaujOw9AsvS for <>; Mon, 30 Jan 2017 23:22:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 872F8129437 for <>; Mon, 30 Jan 2017 23:22:00 -0800 (PST)
Received: by with SMTP id v96so29269609ioi.0 for <>; Mon, 30 Jan 2017 23:22:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pTAVryKJFcZrOH2+DIg0RxT1spvyFTEOFkY4eX//f24=; b=R1mgeAyPx21EJlEJkuq99VJuhcPVHe4ThlJDjtUKWwAgB4irKckZDmNf/Ip5ax8aoj UpQ4gp+dO/j5qa1f2p0Fi5SGxjMaS1BZu8OtJEUu5tqsibvCnsllZrr4ExfBGRXRhoRu RaIEld/F/p0JUPXBNpc2AHpYmpWbRVLB9un6s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pTAVryKJFcZrOH2+DIg0RxT1spvyFTEOFkY4eX//f24=; b=q8l/qrgPk0XtkWB8KoSSjL48Qe0UY1004mX7nFpLK+XyccY0Alc6TjcCCZXkzkeo4c 0j9BKOdaX5Z0HKml5GLn2e4GeXb2w9ucs3ewAnG7oFWPMDoVm1yamKO0mt2KlpesU31z aWGx5u+NL4Ct9B1GHf8Ocrk0KWlVabeK6IL6EFYU0VoDO4trCqLlPnJgKg7ZFn2EQLTJ ehjCqdyPEVNH9hP30pN+pjO3/5GJKVF1LaLfcSf04XiC3Lawcp5aG/g8N1vFm38sHsLW LsHr6lB8qd6vYS9l8wLOzPpeI8Sj0wybGw3J4qsMfNHCwQwzJalZCOTN8A4cBFqu0bio DQ3Q==
X-Gm-Message-State: AIkVDXL4BJK09n/ySiA+9dc4S7kTulxxmXJvyPg1JKIMIsywXcJstRkVMho/Ck+JBdLSbeDT5aWcC6SXAvqqT4QP
X-Received: by with SMTP id c8mr24685477iog.160.1485847319746; Mon, 30 Jan 2017 23:21:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 30 Jan 2017 23:21:59 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Xavi Vilajosana Guillen <>
Date: Tue, 31 Jan 2017 08:21:59 +0100
Message-ID: <>
Subject: Re: [6tisch] Last Call: <draft-ietf-6tisch-minimal-17.txt> (Minimal 6TiSCH Configuration) to Best Current Practice
To: Ralph Droms <>
Content-Type: multipart/alternative; boundary=94eb2c1bfb74af320605475ec97e
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 07:22:03 -0000

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.

> 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:

> - Ralph

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
[image: Universitat Oberta de Catalunya]