Home Automation Routing Requirements in Low-Power and Lossy Networks
draft-ietf-roll-home-routing-reqs-11

I am supporting Pasi's DISCUSS about conflict of zero-configuration with security.

3.5. Scalability

   Looking at the number of wall switches, power outlets, sensors of
   various nature, video equipment and so on in a modern house, it
   seems quite realistic that hundreds of low power devices may form
   a home automation network in a fully populated "smart" home.
   Moving towards professional building automation, the number of
   such devices may be in the order of several thousands.

   The routing protocol MUST support 250 devices in the network.

Should this be "... MUST support at least 250 devices ...".
And to use Chris Newman's trick: why not say 257?

> Unlike other categories of Personal Area Networks (PANs), the
> connected home area is very much consumer-oriented.

Surely this is not true. I think most sports performance measurement
gear, phone & music player, etc. applications are very consumer
oriented. Perhaps you meant to say that other ROLL areas (like
industrial plant monitoring) are less consumer oriented than home
and PAN areas.

> One event may cause many actuators to be activated at the same
> time.
> Using the direct analogy to an electronic car key, a house owner
> may activate the "leaving home" function from an electronic house
> key, mobile phone, etc. For the sake of visual impression, all
> lights should turn off at the same time. At least, it should
> appear to happen at the same time. A well-known problem in
> wireless home automation is the "popcorn effect": Lamps are turned
> on one at a time, at a rate so slow that it is clearly visible.

I am wondering what value this paragraph adds. This may be a well
known problem, but it is certainly one of poor implementation
and/or choice of L2. I have a very hard time seeing this being
a problem due to routing, or even being a problem in a well
design network. In particular when home networks are naturally
quite limited in physical size, unlike factories or commercial
buildings.

> If assignment of unique addresses is performed by a central
> controller, it must be possible to route the inclusion request
> from the joining node to the central controller before the joining
> node has been included in the network.

While this requirement is logical, I wonder to what extent it assumes
that we somehow have to redo many of the basic building blocks and 
concepts that we have in IP networks. Does ROLL require something
AUTOCONF-like? I would certainly hope that we can still have
subnets and the basics of IP addressing stay the same, and that
things like DHCP and DHCP relays work.

> In contrast to other applications, e.g. industrial sensors, where
> data would mainly be originated by a sensor to a sink and vice
> versa, this scenario implicates a direct inter-device
> communication between ROLL devices.

I'm not convinced that the home network is any more peer-to-peer
driven than other environments. Most equipment that we have today
is still centrally controlled, even if running on top of IP.

Section 3.2., paragraph 4:
>    The routing protocol MUST provide mobility with convergence time
>    below 0.5 second if only the sender has moved.

  There's an unstated assumption here regarding the size/diameter of the
  network. You might want to point to Section 3.5 here.


Section 3.8., paragraph 1:
>    The routing protocol MUST support the ability to isolate a
>    misbehaving node thus preserving the correct operation of the
>    overall network.
>    In other words, if a node is found to fail often compared to the
>    rest of the network, this node should not be the first choice for
>    routing of traffic.

  At least to me, the second paragraph isn't talking about the same
  thing as the first paragraph. The first one says "never use", the
  second says "not prefer."


Section 2.1., paragraph 3:
>    acknowledged singlecast messages to each device.

  Nit: s/singlecast/unicast/ (?)

The prose frequently assumes radio-based wireless.  The charter for the
group calls out other technologies.  Is it possible that some
requirements motivated by those other technologies have been missed?

You might want to consider devices like robot-vacuum cleaners as nodes
that can be both transmitters and receivers that will be highly
portable.

(Pasi captured this better in his discuss, but this was already written so I'm leaving it here to inform that conversation).
Has the group begun to explore the conflict between the authentication
requirements in the security consideration section and the
zero-configuration for access requirements earlier in the document? If
so, capturing some of that discussion would be helpful. If not, there
may be related requirements that the group hasn't uncovered yet.

---- Old DISCUSS text downgraded to Comments ----

I support Lars' discuss regarding requirements on applications vs requirements on the routing protocol.

There are several constants presented as requirements without
motivation. Where did the .5 second, 2 second, and 4 second
convergence times come from? Why is the receiver-moved-only
requirement in 3.2 separated in the text from the sender-moved-only
requirement in 3.6?

What is section 4 informing? If it is truly necessary, then many of the
claims (frequency of switch/remote use, frequency of sensor reporting)
needs to point to some reference for authority. The end of that section
also makes some claims about mechanism ("typically as UDP" for
example) that are out of place. Can the section be deleted?

The paragraph motivating "MUST support 250 devices" is not persuasive
(plugs and switches are not inherently going to be low-power nodes).
What led to the choice of this particular constant?

I share Pasi's and Cullen's discuss regarding the disconnect between security requirements and zero configuration requirements.