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

[peter van der Stok <[e-mail]>]

HI Michael,

The use case I like to be covered seems less complex than the ones you 
describe below.

Suppose:
A new building is installed with building equipment such as HVAC, 
lighting, etc.
Or an existing building is retrofit.
Cables are laid out, connected to equipment, Access Points are 
installed, 6LBRs are installed,
and wireless equipment connecting to the 6LBRs and APs is installed.
Cabling is tested and wrong connections are removed.

Assuming the cabling, the 6LBRs and APs are correctly installed, the 
network is powered up.
Assume most equipment is ANIMA enabled. The network is bootstrapped with 
factory security in place.
After bootstrap this is a perfect moment to decide whether the network 
(ACP) works or not.

Once the network is declared to work (satisfies the specification), 
additional service discovery, group declarations, application specific 
keying material can be installed.

Such a network will be composed of LLNs, and includes constrained 
devices.
Sleepy nodes (energy harvesting sensors) may include ANIMA services, but 
special provisions to include them in the network are more likely to be 
deployed.

For the moment I have no idea what ACP and Anima bootstrapping implies 
in terms of resources and resource consumption.
But excluding everything smaller than a tablet may be premature.

Peter

Michael Richardson schreef op 2015-11-30 22:39:
> 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 =-
> 
> 
> 
> 
> _______________________________________________
> Anima-bootstrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima-bootstrap