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

Michael Richardson <> Sun, 23 February 2020 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9E9D3A0F86; Sun, 23 Feb 2020 13:23:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CA8JDHF4qPxJ; Sun, 23 Feb 2020 13:23:50 -0800 (PST)
Received: from ( [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 (Postfix) with ESMTPS id 023423A0F85; Sun, 23 Feb 2020 13:23:42 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id E38333897C; Sun, 23 Feb 2020 16:22:41 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id C8643A8C; Sun, 23 Feb 2020 16:23:40 -0500 (EST)
From: Michael Richardson <>
To: Alvaro Retana <>
cc:,, Pascal Thubert <>, The IESG <>,
In-Reply-To: <>
References: <> <29710.1582208163@dooku> <> <20565.1582316488@dooku> <>
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: Sun, 23 Feb 2020 16:23:40 -0500
Message-ID: <27353.1582493020@localhost>
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: Sun, 23 Feb 2020 21:23:53 -0000

Alvaro Retana <> wrote:
    >> Alvaro Retana wrote:
    >> > The text you propose helps a little, but it makes me uneasy that a
    >> > significant part of the (1!) structure defined in a Standards Track
    >> > document is experimental. Also, the fact that the WG does not in
    >> > general have a clear prescription and that there's work to be done in
    >> > RPL, makes the text sound speculative.
    >> > It would be more appropriate (again, for a Standards Track document) to
    >> > simply declare the specific use and determination of the different
    >> > priorities as out of scope (vs the subject of future research). You
    >> > might still want to include a separate non-normative section (or an
    >> > appendix) to deal with "future work", but having that discussion while
    >> > the fields are being specified does not seem right to me.
    >> I understand your point.
    >> I think that it's not much different than BGP4's MED attribute.
    >> I think that 80% of operators still have no idea how to set it :-)

    > Very different!  Setting policies in BGP is not straight forward for
    > some, specially when some of the attributes interact with someone
    > else's policy, which is unknown.  Operators may have a hard time
    > setting the MED, but its behavior is clearly specified.

I claim the same is true for rank priority :-)

    > Interpreting and acting on the values is exactly the piece I have a
    > problem with.  The rank priority is an "indication of how willing this
    > 6LR is to serve as an RPL [RFC6550] parent".  How is the receiver
    > expected to that the value into account for parent selection?  That
    > part is not specified.  The same for the pan priority; the text says
    > that a receiver "MAY consider this value when looking for an eligible
    > parent device",

The intention is not to change the parent selection algorithm at all.
The intention is to help the *PAN* selection algorithm by giving a hint as to
what kind of parents are available on a particular PAN.

Once the PAN has been joined (which may involve an additional onboard process
to get a 2-byte address and local keys, or might just mean pulling some keys
out of NVRAM, and synchrozing to the schedule), then the node can receive
DIOs (possibly from many other possible parents), and run the normal parent
selection algorithm.
But, it can't see multiple PANs.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]        |   ruby on rails    [

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