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

Alvaro Retana via Datatracker <noreply@ietf.org> Wed, 19 February 2020 23:12 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: 6tisch@ietf.org
Delivered-To: 6tisch@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A811D120957; Wed, 19 Feb 2020 15:12:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6tisch-enrollment-enhanced-beacon@ietf.org, Pascal Thubert <pthubert@cisco.com>, 6tisch-chairs@ietf.org, 6tisch@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <158215393967.17661.15214952317681663416.idtracker@ietfa.amsl.com>
Date: Wed, 19 Feb 2020 15:12:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/rVa-0usT-S8VckCohgoHEHGamMY>
Subject: [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
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: Wed, 19 Feb 2020 23:12:22 -0000

Alvaro Retana has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

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.

The rank priority is described as "an indication of how willing this 6LR is to
serve as an RPL {?RFC6550} parent", which points directly at parent selection. 
The only mention (that I could find) in rfc6550 of an indication of how
"willing to act as a parent" a node may be shows up as a guideline when
describing the DAO-ACK.  The relative values ("Lower values indicate more
willing, and higher values indicate less willing.") are aligned, but the size
of the fields is different.  How, if at all, are these values related?

(2) What is the PANID?  Is there a relationship with the DODAGID or the RPL
Instance?

(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.


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