[Roll] comments on draft-phinney-roll-rpl-industrial-applicability

[Michael Richardson <[e-mail]>]

{this email was written in several sittings over 10 days. Probably I
missed some stuff}

Section 1.3 says:
 1.3.  Out of scope requirements
   This applicability statement does not address requirements related to
   wireless LLNs employed in factory automation and related
   applications.

So, as I understand things, this document applies to *plants*, but not
automated factories.   Forgive me for my ignorance, but I guess this
means it applies to a oil refinery or chemical plant, but not to a car
manufacturer. (Even though, we call them "auto plants")

I'm just trying to understand where the line is and why.

====

>The domain of applicability for the RPL protocol may include all
>   phases but the Normal Operation phase, where the bandwidth allocation
>   and the routes are usually optimized by an external Path Computing
>   Engine (PCE), e.g. an ISA100.11a System Manager.

So, RPL could be used during phases P1, P2, P4, P5 and P6, but not
during P3, (Normal Operation), unless a new OF was defined that
interacted with the PCE?

(Last time I read the document, I was sure it said that LLNs could
be used only during P3)

Given that, I guess the "X" in figure 1 means that RPL *can* be used?


section 2.1.2 then says:
   For factory automation networks, the basic communications cycle for
   control is typically much faster, on the order of 100 Hz or more.

but, I thought factory automation was out of scope?

section 2.1.3:
I think that I'm confused about Source-Sink(SS) vs Peer-to-multipeer(P2MP)
given that 2.1.3 says that the sink is usually a multicast address.
Is the distinction that in P2MP multiple packets are unicast?
Or is the distinction that P2MP is primary from outside the LLN,
downward into the LLN, while SS is within the LLN?

Or is it that the source is always on the LLN, and the sink is always
elsewhere, and the fact that it's a multicast/anycast destination is 
just a question of how to implement redundancy in the data collection
systems? 

page 13, section 2.1.4: says: 

   With rare
   exception, the control algorithms used with PS messaging in the
   process automation industries - those managing continuous material
   flows - rely on fixed-period sampling, computation and transfer of
   outputs, while those in the factory automation industries - those
   managing discrete manufacturing operations - rely on bounded delay
   between sampling of inputs, control computation and transfer of
   outputs to physical actuators that affect the controlled process.

it seems that there are possibly two completely different industrial
requirements here which can not, and should not, be satisfied with a
single DAG.  Are two documents appropriate here?

>   Note: Although there are known patent applications for duocast and
>   N-cast, at the time of this writing the patent assignee, Honeywell
>   International, has offered to permit cost-free RAND use in those
>   industrial wireless standards that have chosen to employee the
>   technology, under a reciprocal licensing requirement relative to that
>   use.  

Can we get an official IPR statement via:
    http://www.ietf.org/ipr/file-disclosure

on this?  I don't think it is particularly relevant to the document, but
perhaps I could be wrong.

you need to update [I-D.ietf-roll-rpl] to RFC6550.

4.3.1 says:

> Because the actual link capacity depends on the particular link
> technology used within an industrial automation network deployment,
> the Trickle parameters are specified in terms of the link's maximum
> capacity for conveying link-local multicast messages.  If the link
> can convey m link-local multicast packets per second on average, the
> expected time it takes to transmit a link-local multicast packet is
> 1/m seconds.

I am pleased that a formula is being provided, but I am uncomfortable
that this document is not more specific to actual link technology used.
Can this document pick 1-2 actual link technologies and deal with them?

5.:
  > The possibility of dynamically updating the metrics in use in the
  > network as well as the frequency of network updates allows deployment
  > characteristics (e.g., network density) to be discovered during
  > network bring-up and to be used to tailor network parameters once the
  > network is operational rather than having to rely on precise pre-
  > configuration.  This also allows the network parameters and the
  > overall routing protocol behavior to evolve during the lifetime of
  > the network.

I don't know how this discovery is going to occur.
Someone trying to build a sensor that is going to satisfy an RFP for
devices to work in a network envisioned by this document needs to know
what to include in their code base.   As the code space is very finite,
they need to know exactly what is important here.

-- 
Michael Richardson <[e-mail]>, Sandelman Software Works