Subject: [6tisch] WG adoption of the “IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information” document

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 15 Jun 2018 14:53:59 +0000

Dear WG:

As discussed during the last interim, we are calling for WG adoption of the “IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information” document:

https://datatracker.ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/

This work is discussed at 6TiSCH and ROLL. Please provide feedback by June 29th, 2018, 21:00 CEST, so we can have a draft-ietf-.. published before cutoff.

All the Best,
Pascal and Thomas

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 18 Jun 2018 17:32:15 +0200

Hi,

This proposal looks useful. I like the idea of Network ID!

I'm sharing my comments on the draft:

  https://tools.ietf.org/html/draft-richardson-6tisch-enrollment-enhanced-beacon-01

[1] (trivial comment)

draft>   There are a limited number of timeslots designated as a broadcast
draft>   slot by each router.  These slots are rare, and with 10ms slots, with
draft>   a slot-frame length of 100, there may be only 1 slot/s for the
draft>   beacon.

It may be more natural to use a slot-frame length of *101* since RFC
8180 is referred in the beginning of the same section...

[2] RS/RA confusion...?

draft> 1.3.  Layer-3 synchronization IPv6 Router solicitations and
draft>       advertisements
draft> ...
draft>   unsolicited RAs; if a pledge node does not hear an RA, and decides to
draft>   send a RS (consuming a broadcast aloha slot with unencrypted
draft>   traffic), many unicast RS may be sent in response.

The last sentence should be "many unicast RA may be sent in response"?

draft>  2.  it may require many seconds of on-time before a new pledge hears
draft>       a Router Soliciation that it can use.

This also should be "Router Advertisement" instead of "Router
Solicitation"?

draft>   3.  a new pledge may listen to many Enhanced Beacons before it can
draft>       pick an appropriate network and/or closest Join Assistant to
draft>       attach to.  If it must listen for a RS as well as find the
draft>       Enhanced Beacon, then the process may take a very long time.

Same here. s/RS/RA/

[3] (trivial comment)

draft> 2.  Protocol Definition
draft> ...
draft>                         1                   2                   3
draft>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
draft>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft>    |   TBD-XXX     |R|P| res |  proxy prio |    rank priority      |
draft>    +-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
draft> ...
draft>    |               |
draft>    +-+-+-+-+-+-+-+-+
draft> 
draft>    proxy priority  the proxy prority value contains a number from 0 to
draft>       0x7f.  Lower numbers are considered to be a higher preference.  A
draft>       priority of 0x7f indicates that the announcer should never be
draft>       considered as a viable enrollment proxy.  Lower value indicates
draft>       willing to act as a Join Proxy as described in
draft>       [I-D.ietf-6tisch-minimal-security].  Only unenrolled pledges look
draft>       at this value.
draft> 
draft>    pan priority  the pan priority is a value set by the DODAG root to
draft>       indicate the relative priority of this LLN compared to those with
draft>       different PANIDs.  This value may be used as part of the
draft>       enrollment priority, but typically is used by devices which have
draft>       already enrolled, and need to determine which PAN to pick.
draft>       Unenrolled pledges MAY consider this value when selecting a PAN to
draft>       join.  Enrolled devices MAY consider this value when looking for
draft>       an eligible parent device.

It would be easier for readers if the order of the field definitions
is the same as the order the fields appear in the figure.

[4] Proxy Address bit

draft>   P  if the Proxy Address bit is set, then the lower 64-bits of the
draft>      Join Proxy's Link Layer address follows the network ID.

It seems the lower 64-bits of the Join Proxy's Link Layer address *is
followed by* the Network ID in the figure.

draft>       Join Proxy's Link Layer address follows the network ID.  If the
draft>       Proxy Address bit is not set, then the Link Layer address of the
draft>       Join Proxy is identical to the Layer-2 8-byte address used to
draft>       originate this enhanced beacon.

By definition, an Enhanced Beacon cannot have a 2-octet link-layer
address in its source address field? Or, if P bit is set, a
transmitter should set its 8-octet link-layer address to the source
address field of an enhanced beacon?

[5] Join-Proxy Address

draft>    join-proxy lower-64  if the P bit is set, then 64 bits (8 bytes) of
draft>       address are present.  The Link Layer address of the Join Proxy is
draft>       fe80 (as for any Link Layer address), and the bits given in this
draft>       field.

The last sentence is unclear to me... Does it mean that a link-local
IPv6 address of the Join Proxy can be generated by the bits given in
the field with the link-local prefix, fe80::/64?

[6] Network ID

dfaft>    network ID  this is an variable length field, up to 16-bytes in size
dfaft>       that uniquely identifies this network, potentially among many
dfaft>       networks that are operating in the same frequencies in overlapping
dfaft>       physical space.

Can we omit the network ID field?

Best,
Yatch

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Tue, 19 Jun 2018 16:19:09 +0200

Hello,

I like this work and I found it useful. 
Some points that we discussed at the IETF 101 in London is already included, e.g., pan priority, rank priority.

Cheers,
Georgios

> On Jun 15, 2018, at 16:53, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> Dear WG:
> 
> https://datatracker.ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/ <https://datatracker..ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/>
> _______________________________________________
> 6tisch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 20 Jun 2018 09:27:05 +0530

I support adoption of this work and will review the document.
Although currently coupled with 6tisch/802.15.4, I believe this doc
might help in non-6tisch adhoc mesh scenarios as well.

- Rahul
On Fri, 15 Jun 2018 at 20:24, Pascal Thubert (pthubert)
<pthubert=[email-masked]> wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jun 2018 22:17:17 -0400

> might help in non-6tisch adhoc mesh scenarios as well.

The other thing in the Enhanced Beacon is the 6tisch schedule, but if you
don't need that and aren't going to be synchronizing, the contents of this
IE can still be used.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 22 Jun 2018 13:34:42 +0000

Hi:

6TiSCH hat chair off, and as a ROLL participant as well, I support the adoption. Note that the ROLL impact has to do with fast DODAG selection in a multitenant radio environment.

Cheers,

Pascal

From: 6tisch <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 15 juin 2018 16:54
To: [email-masked]
Subject: [6tisch] WG adoption of the “IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information” document

Dear WG:

https://datatracker.ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/<https://datatracker..ietf.org/doc/draft-richardson-6tisch-enrollment-enhanced-beacon/>

All the Best,
Pascal and Thomas