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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 19 Feb 2020 15:12:19 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

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.

The rank priority is described as "an indication of how willing this 6LR is to
serve as an RPL {?RFC6550} parent", which points directly at parent selection. 
The only mention (that I could find) in rfc6550 of an indication of how
"willing to act as a parent" a node may be shows up as a guideline when
describing the DAO-ACK.  The relative values ("Lower values indicate more
willing, and higher values indicate less willing.") are aligned, but the size
of the fields is different.  How, if at all, are these values related?

(2) What is the PANID?  Is there a relationship with the DODAGID or the RPL
Instance?

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

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 15:16:03 +0100

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-masked]> 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.

    > §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  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 20 Feb 2020 09:55:49 -0800

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

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

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

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

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

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 20 Feb 2020 12:32:38 -0600

On February 20, 2020 at 9:16:06 AM, Michael Richardson wrote:

...
> Alvaro Retana via Datatracker wrote:
...

> split it up into multiple TLV.

Michael:

Hi!

The text you propose helps a little, but it makes me uneasy that a significant
part of the (1!) structure defined in a Standards Track document is
experimental.  Also, the fact that the WG does not in general have a clear
prescription and that there's work to be done in RPL, makes the text sound
speculative.

It would be more appropriate (again, for a Standards Track document) to simply
declare the specific use and determination of the different priorities as out
of scope (vs the subject of future research).  You might still want to include
a separate non-normative section (or an appendix) to deal with "future work",
but having that discussion while the fields are being specified does not seem
right to me.

Thanks!

Alvaro.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Feb 2020 15:17:01 -0500

I will update the new section in -14, which I'll post in a few minutes so
that the WG can review the result.

Benjamin Kaduk <[email-masked]> wrote:
    >> +## 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

Agreed.
        + In a complex Low-power and Lossy Networks (LLN), multiple LLNs may
        be connected together by backbone routers ( technology such as
        {{?I-D.ietf-6lo-backbone-router}}), resulting in an area that is
        serviced by multiple distinct Layer-2 instances.

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

done

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

agreed.

    >> 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"?

Agreed, thank you.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Feb 2020 15:21:28 -0500

WG: what do you think?

    mcr> The goal of this document is to provide a container for a number of
    mcr> somewhat unrelated things, and do this in a on-the-wire efficient
    mcr> way. Otherwise we'd split it up into multiple TLV.

Alvaro Retana <[email-masked]> wrote:
    > The text you propose helps a little, but it makes me uneasy that a
    > significant part of the (1!) structure defined in a Standards Track
    > document is experimental.  Also, the fact that the WG does not in
    > general have a clear prescription and that there's work to be done in
    > RPL, makes the text sound speculative.

    > It would be more appropriate (again, for a Standards Track document) to
    > simply declare the specific use and determination of the different
    > priorities as out of scope (vs the subject of future research).  You
    > might still want to include a separate non-normative section (or an
    > appendix) to deal with "future work", but having that discussion while
    > the fields are being specified does not seem right to me.

I understand your point.
I think that it's not much different than BGP4's MED attribute.
I think that 80% of operators still have no idea how to set it :-)

We don't know how to *set* the value, but we *do* know how to interpret
different values.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 21 Feb 2020 12:58:13 -0800

On February 21, 2020 at 3:21:29 PM, Michael Richardson wrote:
> Alvaro Retana wrote:

Very different!  Setting policies in BGP is not straight forward for
some, specially when some of the attributes interact with someone
else's policy, which is unknown.  Operators may have a hard time
setting the MED, but its behavior is clearly specified.

> We don't know how to *set* the value, but we *do* know how to interpret

Interpreting and acting on the values is exactly the piece I have a
problem with.  The rank priority is an "indication of how willing this
6LR is to serve as an RPL [RFC6550] parent".  How is the receiver
expected to that the value into account for parent selection?  That
part is not specified.  The same for the pan priority; the text says
that a receiver "MAY consider this value when looking for an eligible
parent device", ok...how?

Alvaro.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Feb 2020 16:23:40 -0500

> setting the MED, but its behavior is clearly specified.

I claim the same is true for rank priority :-)

    > parent device", ok...how?

The intention is not to change the parent selection algorithm at all.
The intention is to help the *PAN* selection algorithm by giving a hint as to
what kind of parents are available on a particular PAN.

Once the PAN has been joined (which may involve an additional onboard process
to get a 2-byte address and local keys, or might just mean pulling some keys
out of NVRAM, and synchrozing to the schedule), then the node can receive
DIOs (possibly from many other possible parents), and run the normal parent
selection algorithm.
But, it can't see multiple PANs.

https://datatracker.ietf.org/meeting/101/materials/slides-101-6tisch-ietf101-6tisch-i-draft-richardson-6tisch-enrollment-enhanced-beacon-00

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

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 25 Feb 2020 09:01:47 -0800

...
> https://datatracker.ietf.org/meeting/101/materials/slides-101-6tisch-ietf101-6tisch-i-draft-richardson-6tisch-enrollment-enhanced-beacon-00

The slides help a lot and now I understand! :-)

It would be great if the text reflected more what the slides say, but
given the background, I think that what you added in -14 is good
enough...and in any case it doesn't justifies keeping my DISCUSS, so
I'm clearing.

Thanks!!

Alvaro.