Re: [Anima-bootstrap] IoT and scope of bootstrap

[Michael Richardson <[e-mail]>]

peter van der Stok <[e-mail]> wrote:
    > Hi Michael,

    > Your text proposal does not help me much.

Oh, I am sad.

peter van der Stok <[e-mail]> wrote:
    >> +      <section title="Scope of solution">
    >> +        <t>
    >> +          Questions have been posed as to whether this solution is suitable
    >> +          in general for Internet of Things (IoT) networks.  In general the
    >> +          answer is no, but the terminology of <xref target="RFC7228" /> is
    >> +          best used to describe the boundaries.
    >> +        </t>

    > The above text is much more restrictive than the text below.

So, my intention is to make people argue why IoT should be covered, rather
than assume it is unless not specified.

    >> +        <t>
    >> +          Specifically, there are protocol aspects described here which might
    >> +          result in congestion collapse or energy-exhaustion of intermediate
    >> +          battery powered routers in an LLN.  Those types of networks SHOULD
    >> +          NOT use this solution.
    >> +        </t>
    >> +      </section>

    > I think the text about battery-powered or energy harvesting devices is the
    > more appropriate.

Agreed.

    > What about text that formulates unwanted side effects coming from energy
    > exhausted ("dead") nodes?
    > I don't think the dying of a node is allowed to jeopardize the functioning
    > for other nodes or cause congestion, as your text suggests.

    > Some effort on getting this right is worthwhile, because I think the use of
    > the anima Bootstrap may be interesting for the installation of large control
    > networks, where
    > the verification of the correct functioning of the network as such is clearly
    > separated from the correct functioning of the (control-)
    > application on top.

Here is a use case that I imagine.

There is an existing LLN with a 6LBR and a backbone connection.
By construction, it has some energy constrained nodes in it, which function
just fine.

The LLN is to be expanded to service some new requirement. While the existing
6LBR can reach the new space, it won't work reliably enough, so a new 6LBR is
installed in the new space.  The 6LBR is ANIMA capable, and is mains powered,
and the new backhaul will be 802.11.  The new device doesn't have WEP/WPA
keys (and the AP doesn't speak ANIMA), but it does speak the 6tisch join
protocol, so it joins the existing LLN as a leaf.  Then, using the LLN, it
performs an *ANIMA* enrollment, with the LLN acting as a single "link" from
the ANIMA point of view.

Once enrolled, it has a domain specific certificate, has been provisioned
with the right WEP key, and can now enable the wifi as backbone.

Another use case might be a BFR in a cabinet that is being cabled up, but
said cables are not yet "lit".  It has been given a BTLE USB key into one of
it's USB slots usually intended for firmware updates.  The BFR does a pairing
over BTLE with the installers' smartphone, and using rfc7688, and connects to
the ACP that the smartphone is part of.  The BFR is now "up" enough for the
experts in the NOC to bring things up.  They might need to configure the
right lambdas for the 100G link to turn on... or instruct the cabling people
which cable goes into which port. (cables *never* get mis-labelled..)

In this context, the smartphone is energy constrained, and getting the ACP
off of it ASAP would be important.

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