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

[Benjamin Kaduk <[e-mail]>]

On Thu, Feb 20, 2020 at 03:16:03PM +0100, Michael Richardson wrote:
> 
> 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

I think there's a botched edit in here; it doesn't seem to parse properly.

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

"security mechanisms", please.

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

This looks like it started out as a 3+-element list and got edited down to
just two, with a stray comma and no "or".

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

This makes it sound like the actual structure might change, which I don't
think is the intent.  So perhaps "the interpretation of this value of the
structure is considered experimental"?

Thanks,

Ben