Re: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)

Michael Richardson <> Fri, 21 February 2020 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 092FA12006B; Fri, 21 Feb 2020 12:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.501
X-Spam-Level: **
X-Spam-Status: No, score=2.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UT6PZ0rHfuyf; Fri, 21 Feb 2020 12:17:05 -0800 (PST)
Received: from ( [IPv6:2a01:7e00::3d:b000]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1050012003E; Fri, 21 Feb 2020 12:17:04 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id 10AD71F458; Fri, 21 Feb 2020 20:17:03 +0000 (UTC)
Received: by (Postfix, from userid 179) id 8666F1A2BAC; Fri, 21 Feb 2020 21:17:01 +0100 (CET)
From: Michael Richardson <>
To: Benjamin Kaduk <>
cc: Alvaro Retana <>,, Pascal Thubert <>,, The IESG <>,
In-reply-to: <>
References: <> <29710.1582208163@dooku> <>
Comments: In-reply-to Benjamin Kaduk <> message dated "Thu, 20 Feb 2020 09:55:49 -0800."
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Fri, 21 Feb 2020 15:17:01 -0500
Message-ID: <20152.1582316221@dooku>
Archived-At: <>
Subject: Re: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with DISCUSS and COMMENT)
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Feb 2020 20:17:07 -0000

I will update the new section in -14, which I'll post in a few minutes so
that the WG can review the result.

Benjamin Kaduk <> wrote:
    >> +## Layer-2 Selection + +In a complex Low-power and Lossy Network
    >> (LLN), the use of mulitple backbone routers connected together by
    >> technology such as {{?I-D.ietf-6lo-backbone-router}} an area may be
    >> serviced by multiple distinct

    > I think there's a botched edit in here; it doesn't seem to parse
    > properly.

        + In a complex Low-power and Lossy Networks (LLN), multiple LLNs may
        be connected together by backbone routers ( technology such as
        {{?I-D.ietf-6lo-backbone-router}}), resulting in an area that is
        serviced by multiple distinct Layer-2 instances.

    >> +Layer-2 instances.  +These are called PANs.  +Historically, this term
    >> meant "Personal Area Network", but the use of the word "Personal" is
    >> now deprecated.  +Each instance will have a separate Layer-2 security
    >> profile, and will be distinguished by a different PANID.  +The PANID
    >> is part of the {{ieee802154}} layer-2 header: it is a 16-bit value
    >> which is chosen to be unique, and it contributes context to the
    >> layer-2 security.

    > "security mechanisms", please.


    >> +The PANID provides a context similar to the ESSID does in 802.11
    >> networking, and can be conceived of in a similar fashion as the 802.3
    >> ethernet VLAN tag in that it provides context for all layer-2
    >> addresses.  + +A device which is already enrolled in a network may
    >> find after a long sleep that it needs to resynchronize to the Layer 2
    >> network.  +The enrollment keys that it has will be specific to a
    >> PANID, but it may have more than one set of keys.  +Such a device may
    >> wish to connect to a PAN that is experiencing less congestion, which
    >> has a shalower RPL tree.

    > This looks like it started out as a 3+-element list and got edited down
    > to just two, with a stray comma and no "or".


    >> announcer is.  +Once the device synchronizes to a particular PAN's
    >> TSCH schedule then it may receive DIOs that are richer in their
    >> diversity than this value.  +How this value will be used in practice
    >> is the subject of future research, and this part of the structure +is
    >> considered experimental.

    > This makes it sound like the actual structure might change, which I
    > don't think is the intent.  So perhaps "the interpretation of this
    > value of the structure is considered experimental"?

Agreed, thank you.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-