IETF Logo Mail Archive

Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 23 July 2018 13:45 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 157B0131095 for <6tisch@ietfa.amsl.com>; Mon, 23 Jul 2018 06:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 ndw3qZeT71S2 for <6tisch@ietfa.amsl.com>; Mon, 23 Jul 2018 06:45:48 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9781130F08 for <6tisch@ietf.org>; Mon, 23 Jul 2018 06:45:48 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8D95B2008D; Mon, 23 Jul 2018 10:01:53 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 83C8D12A6; Mon, 23 Jul 2018 09:45:47 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7D21721; Mon, 23 Jul 2018 09:45:47 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Randy Turner <rturner@amalfisystems.com>
cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <5F22E55B-951F-402E-BEA1-B296A374F6C2@amalfisystems.com>
References: <153213124330.11513.14157137359028132358@ietfa.amsl.com> <97ae9b210390401bae2e50d82fc7324c@XCH-RCD-001.cisco.com> <20659.1532209070@localhost> <5F22E55B-951F-402E-BEA1-B296A374F6C2@amalfisystems.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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-sha1"; protocol="application/pgp-signature"
Date: Mon, 23 Jul 2018 09:45:47 -0400
Message-ID: <15655.1532353547@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ikXyix7jsKWW7hJFT_6PkXcUyKo>
Subject: Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.27
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, 23 Jul 2018 13:45:57 -0000

Randy Turner <rturner@amalfisystems.com> wrote:
    > Looking at the enrollment-enhanced-beacon draft, I think some vendors
    > already employ this technique to address the bandwidth issues you
    > raise
    > in the draft (advertisement slots, etc.)….so the rationale for this
    > draft is probably well established. I had a couple of comments on this
    > early text…

    > - Section 2, “Network Name” - would this serve the same purpose as an
    > 802.11 “SSID” ?

Yesish.
My intent is that this is not something that is selected, but rather
something that is easily calculated in a RPL network from the DIO.

    > - It looks like a join assistant would be chosen based on examining
    > “network id” first, then “PAN priority”, and then “proxy priority”.
    > And the “rank priority” would somehow be passed across layers to RPL
    > for subsequent parent selection. Is this correct?

As I understand the desire, there is a desire to balance between different
PANs, and to do some of this via RPL values.  So, the rank priority would
influence which network to join.  Parent selection would occur afterwards
as normal.

    > - In section 1.3, there is text that says...
    > if a pledge node does not hear an RA, and decides to
    > send a RS (consuming a broadcast aloha slot with unencrypted
    > traffic), many unicast RS may be sent in response.

That's about a node operating as a leaf (a host), rather than as a router.

    > I *think* you mean to say “…many unicast RAs may be sent in response.”

I'm not sure what belongs here.
I was going to say, many->MAY, but I think the whole paragraph needs
adjustments.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


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

v2.23.0 | Report a Bug | By Email