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

Benjamin Kaduk <kaduk@mit.edu> Thu, 20 February 2020 17:55 UTC

Return-Path: <kaduk@mit.edu>
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 E5FC312004E; Thu, 20 Feb 2020 09:55:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 e5k__OnHj1Ab; Thu, 20 Feb 2020 09:55:57 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDCE120024; Thu, 20 Feb 2020 09:55:57 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01KHtnI0025543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Feb 2020 12:55:52 -0500
Date: Thu, 20 Feb 2020 09:55:49 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, 6tisch@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org
Message-ID: <20200220175549.GG97652@kduck.mit.edu>
References: <158215393967.17661.15214952317681663416.idtracker@ietfa.amsl.com> <29710.1582208163@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <29710.1582208163@dooku>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/XmQrWqDyodDp7toOZU1K4B19e44>
Subject: Re: [6tisch] Alvaro Retana's Discuss on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (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: Thu, 20 Feb 2020 17:56:00 -0000

On Thu, Feb 20, 2020 at 03:16:03PM +0100, Michael Richardson wrote:
> 
> Dear WG, there is text at the end which needs WG review before it goes into -14.
> also at: https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/c312cbf4ebc05255e390595e82f9cbcce2237c34
> 
> Alvaro Retana via Datatracker <noreply@ietf.org> wrote:
>     > I am balloting DISCUSS because the relationship between this document
>     > and RPL parent selection is not clear.  I expect that the issues I
>     > point at will be easy to address, either by clarifying the text or my
>     > potential confusion.
> 
>     > It is not clear to me what is the "RPL status" of an enrolled node.
>     > IOW, is an enrolled node to be considered one that has joined a DODAG
>     > already?  This is then causing some confusion on how RPL parent
>     > selection and the new structure defined here are related.  More
>     > details/questions below.
> 
>     > (1) rank priority
> 
> Well, I thought this might happen when the research people started to ask for
> more interesting data for which they didn't know *exactly* how they might use :-)
> 
>     > What is the relationship between the rank priority and parent selection
>     > as described in rfc6550?  The text says that "it is to help enrolled
>     > devices only to compare different connection points", but no details on
>     > the use are provided.
> 
> I would say that we not in general have a clear prescription, and that there
> will be quality of implementation differences followed by a BCP once people
> figure this out in the field.  Additionally, there is work yet to do in RPL
> to configure some of these things correctly, but this is the first document
> to come forward to the IESG, and while draft-ietf-roll-enrollment-priority-00
> was written to accomodate the enrollment part of things, there are not yet
> similar drafts to explain the other values.
> 
> The goal of this document is to provide a container for a number of somewhat
> unrelated things, and do this in a on-the-wire efficient way.  Otherwise we'd
> split it up into multiple TLV.
> 
>     > (2) What is the PANID?  Is there a relationship with the DODAGID or the
>     > RPL Instance?
> 
> It's a Layer-2, 802.15.4 thing, akin to ESSID, or VLAN-number.
> 
>     > (3) The text says that the pan priority "typically is used by devices
>     > which have already enrolled...MAY consider this value when looking for
>     > an eligible parent device."  As with the rank priority, there are no
>     > details about how a node may use this value during parent selection.
> 
> Devices which have not enrolled can not meaningfully use PAN priority, they
> use networkID only to avoid attempting (and failing) to enroll to a network
> that does not want them repeatedly.
> 
>     > ----------------------------------------------------------------------
>     > COMMENT:
>     > ----------------------------------------------------------------------
> 
>     > §2 says that the "network ID...[is]...communicated by the RPL
>     > Configuration Option payloads".  I scanned rfc6550, but couldn't find a
>     > place where the network ID is mentioned.  Maybe I'm looking in the
>     > wrong place -- please point me in the right direction.
> 
> There is no such place, it is work to be done.
> 
> I have added the following section/text.
> 
> +## 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.

> +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".

> +It may even observe PANs for which it does not have keys, but which is believes it may have credentials that would allow it to join.
> +
> +In order to identify which PANs are part of the same backbone network, the network ID is introduced in this extension.
> +PANs that are part of the same backbone will be configured to use the same network ID.
> +For {{RFC6550}} RPL networks, configuration of the network ID can be done with an configuration option, which is the subject of future work.
> +
> +In order to provide some input to the choice of which PAN to use, the PAN priority field has been added.
> +This lists the relative priority for the PAN among different PANs.
> +Every Enhanced Beacon from a given PAN will likely have the same PAN priority.
> +Determination of the the PAN priority is the subject of future work; but it is expected that it will be calculated by an algorithm in the 6LBR, possibly involving communication between 6LBRs over the backbone network.
> +
> +The {{RFC6550}} parent selection process can only operate within a single PAN, because it depends upon receiving RPL DIO messages from all available parents.
> +As part of the PAN selection process, the device may wish to know how deep in the LLN mesh it will be if it joins a particular PAN, and the rank priority field provides an estimation of what the rank of each 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"?

Thanks,

Ben