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

[Michael Richardson <[e-mail]>]

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 <[e-mail]> 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
+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.
+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.
+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.
+


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


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-