IETF Logo Mail Archive

Re: [6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 24 February 2020 23:24 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26B73A1572; Mon, 24 Feb 2020 15:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 zVWyDaHxmXiz; Mon, 24 Feb 2020 15:24:02 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01FD53A155A; Mon, 24 Feb 2020 15:24:01 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ADBE738981; Mon, 24 Feb 2020 18:23:00 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A19E8E1B; Mon, 24 Feb 2020 18:23:59 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roman Danyliw <rdd@cert.org>
cc: The IESG <iesg@ietf.org>, "pthubert@cisco.com" <pthubert@cisco.com>, "6tisch-chairs@ietf.org" <6tisch-chairs@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>, "draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org" <draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0216F4BE8E@marchand>
References: <158187587385.5858.4196333441268190800.idtracker@ietfa.amsl.com> <15950.1581956289@dooku> <359EC4B99E040048A7131E0F4E113AFC0216F4BE8E@marchand>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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-sha256"; protocol="application/pgp-signature"
Date: Mon, 24 Feb 2020 18:23:59 -0500
Message-ID: <464.1582586639@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ddVfcf0yLa5_9zwSAzCrxRBzAKs>
Subject: Re: [6tisch] Roman Danyliw's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (with DISCUSS and COMMENT)
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 23:24:09 -0000

Roman Danyliw <rdd@cert.org> wrote:
    >> > ** Section 2.  network id.  Can you please clarify the computation of
    >> > the default value using SHA-256.
    >>
    >> I have changed the text to say:
    >> : In a 6tisch network, where RPL {{RFC6550}} is used as the mesh routing
    >> protocol, the
    >> network ID can be constructed from a truncated SHA256 hash of the prefix
    >> (/64) of the
    >> network.  This will be done by the RPL DODAG root and communicated by
    >> the RPL
    >> Configuration Option payloads, so it is not calculated more than once.
    >> That is just a suggestion for a default algorithm: it may be set in any
    >> convenience way that results in a non-identifing value.

    > Understood.  However, to clarify, is there guidance on how this
    > truncation should be applied (i.e., which bits are supposed to be used?
    > )?

The calculation is
a) a suggestion on how the control plane should initialize itself by default.
b) done once in the 6LBR, so any truncation is acceptable.

I.e. it doesn't matter how it's done.

Communicating the NetworkID down the RPL DODAG is ROLL WG work, which has not
proceeded in pace with this work.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email