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 <[email protected]> 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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
