Industrial Routing Requirements in Low-Power and Lossy Networks
draft-ietf-roll-indus-routing-reqs-06

Here's a solicited review from Thomas Clausen:

The requirements documents present a highly "desirable" set of
properties for routing protocols -- which may not all concurrently be
attainable.

The requirements documents themselves do not try to balance all these
requirements.  This balancing is currently with a DT, which is
trying to (i) understand the depth of the requirements and (ii)
understand how to balance these and (iii) make progress towards an 
acceptable solution, which may involve not satisfying all requirements 
concurrently, but suitable subsets covering all requirements sufficient 
for the deployments. The DT seems to be on a good track and making rapid
progress.

The context of "sensors" is well known in the wg, but is not 
explained quite as well in the documents as they could be; it might
help justify some of the requirement.

The various roll routing  requirement documents lists no less
than 46 "MUST-requirements" and about 30 "SHOULD-requirements".
It s not clear to me that all can be satisfied (individually 
or at the same time). Currently, the groups seems to be going 
through motions of figuring out "how little can we get away 
with doing and still claim to be satisfying the MUSTs". For 
example, "can we get away with full-flooding and receiver filtering,
and still say we satisfy the multicast requirements?"

My 10000ft comments are:

     The wg is in some respects giving the impression of
     chasing a "pie in the sky": essentially, aiming for
     zero-control-traffic, zero-state, zero-footprint
     zero-cost-algorithms -- while getting full IP routing
     (unicast, multicast both), instant convergence,
     shortest paths, QoS, managing networks with 10^5
     routers .... -- I'd love to be able to design such a
     routing protocol.....

     This is the distinct impression that reading the
     documents gives, when paired with some previous
     experience in building wireless routing
     protocols. Speaking to the various authors of ROLL wg
     I-Ds and the wg in general, gives a different picture,
     and it's unfortunate that this is not captured in the
     documents.

     The "routing requirements" documents could be a good
     first-step, outlining the characteristics of the
     "ideal" protocol (pretty much as stated in previous
     paragraph), but a lot of work is required to try to
     arbiter what priorities these "dream properties" have,
     such that reasonable trade-offs can be made. The
     documents do not really help in making this arbitration
     - we've spent a lot of time and effort trying to
     understand what the different MUST/SHOULDs really
     mean....it's a good exercise as such, but I would have
     wished that the process leading to these documents had
     gone through that exercise, though.

     It seems that ROLL is departing in some important ways
     from IP routing, e.g. with hard convergence
     constraints, and intimate linking of transport and
     "routing protocol events" -- see below. My gut feeling
     tells me that it's a layer violation of the dangerous
     kind.

     My main comment is, that as a protocol smith, the
     document doesn't really help me do my job -- I still do
     not believe that I could design a protocol in which I
     could identify to which extend I'd satisfied or not a
     large amount of the "MUSTs" -- there seems to be a lot
     of room for / need for interpretation. Which, in my
     book, should not be the case for MUSTs. (Are
     MUST/SHOULD even appropriate in an informational of
     this nature?)

     My second-main concern is, that I do (still) not think
     that the area that ROLL tries to act within is
     well-specified. On the list, there has been a lot of
     discussion in the past (pre-SF) where some things were
     made clear, e.g. "moores law means smaller, not faster,
     sensors", and "resources of all kind -- battery, state,
     cycles, net -- are very constrained, thing <4KB
     mem". Certainly, if that is the case, the requirements
     are closer to "pie in the sky" -- but this document,
     and indeed any ROLL document, contains nothing to
     either confirm or rebut this.

     If anything, then that would be a Good Thing(TM) to
     state somewhere clearly?

 Details to the industrial routing req. doc:

     Document: The routing protocol MUST be able to compute
         paths of not-necessarily-equal cost toward a given
         destination so as to enable load balancing across a
         variety of paths.

         .....  The routing protocol MUST be able to compute
                a set of unidirectional routes with
                potentially different costs that are
                composed of one or more non-congruent paths.

     Comment: It's not clear if this entails that (a form
         of) MTR is a requirement (and, if so, how it is
         thought done, considering memory constraints), if
         the routing protocol is expected to provide
         disjoint paths (in Wireless, that's not exactly
         trivial to do, considering interference)



     Document: The routing protocol MUST route on paths that
         are changed to appropriately provision the
         application requirements.  The routing protocol
         MUST support the ability to recompute paths based
         on Network Layer abstractions of the underlying
         link attributes/metric that may change dynamically.

     Comment: I'm not sure what "changed to appropriately
         provision the application requirements" means. Nor
         the rest of that sentence.

     Document: The routing protocol MUST enable the full
         discovery and setup of the environment (available
         links, selected peers, reachable network).  The
         protocol also MUST support the distribution of
         configuration from a centralized management
         controller if operator-initiated configuration
         change is allowed.

     Comment: "full discovery and setup of the environment"
         sounds like it is required to maintain "full
         topology" of the network. Which.  it would appear,
         is in stark conflict with the memory constraints.
         It is not clear if this is what is meant, at least
         I have not understood it.

         The latter sentence indicates that some sort of
         "central intelligence" might be charged with doing
         RT calculations for everybody and distributing them
         to the individual routers. It is not clear to me if
         that is the case, but side-discussions seem to
         indicate that this is the intent, even if the words
         are not written to this effect clearly.

     Document: The routing algorithm MUST find the
         appropriate route(s) and report success or failure
         within several minutes, and SHOULD report success
         or failure within tens of seconds.  ....

         The routing algorithm MUST respond to normal link
         failure rates with routes that meet the Service
         requirements (especially latency) throughout the
         routing response.

     Comment: IOW, the Routing Protocol convergence time
         must be bounded by some (arbitrary?) number? What
         does "reporting success or failure" mean, is this a
         transport-issue, an issue of "having paths within
         xx seconds, or signaling to the app?"  or something
         else?

     Document: The routing algorithm SHOULD always be in the
         process of recalculating the route in response to
         changing link statistics.  The routing algorithm
         MUST recalculate the paths when field devices
         change due to insertion, removal or failure, and
         this recalculation MUST NOT cause latencies greater
         than the specified constraints (typically seconds
         to minutes).

     Comment: The "SHOULD always" is somewhat at odds with
         the "convergence" property. The ROLL wg seems to be
         targeting a DV protocol, and the "always be in the
         process of recalculating..." strikes me as for a DV
         protocol to imply "not converging".

         The second part of this text seems directly at odds
         with the first, by listing a set of events where
         paths are to be recalculated. If so, what does it
         mean when it "SHOULD always" be in the process of
         recalculating?

         What is "the route"?

     Document: The routing protocol MUST also support
         different metric types for each link used to
         compute the path according to some objective
         function (e.g. minimize latency) depending on the
         nature of the traffic.

     Comment: I would assume that this translates into
         class-of-service / MTR or some such thing, but
         asking [the wg participants] about this, resulted
         in a "well, it may not be what we want exactly", so
         I do not quite understand what....

     Document: The routing algorithm MUST support
         node-constrained routing (e.g. taking into account
         the existing energy state as a node constraint).
         Node constraints include power and memory, as well
         as constraints placed on the device by the user,
         such as battery life.  Comment: Which is it?
         Continued ("SHOULD always be in the process of
         recalculating the route") CPU-cycle-drain, or
         power-conservation?

     Comment: The security requirements seem to be hard to
         satisfy, given the ressources of the individual
         routers.

     Document: ...the ROLL routing infrastructure is
         required to compute and update constrained routes
         on demand, and it can be expected that this model
         will become more prevalent for field device to
         field device connectivity as well as for some field
         device to Infrastructure devices over time.

         Comment: Not that I have anything against on-demand
         routing, but (i) it's not how IP best-effort is
         usually done, (ii) it may put undue strain on the
         intermediate routers, or even the src
         (buffering). I am not sure that "on-demand" routes
         should be a requirement, but could be an element of
         a solution?

     Document: The routing protocol SHOULD support broadcast
            or multicast addressing.

     Comment: The "or" leaves me bewilded. If I do
         broadcast, is that sufficient?


     Document: The routing protocol SHOULD also support the
         bandwidth allocation for bulk transfers between the
         field device and the handheld device of the
         wireless worker.

     Comment: If this is 1-1 proximity bulk, then OK - if it
         is across-the-network bulk with resource
         reservation, then I am again given the supposed
         constrained characteristics of the devices and
         media, sceptical if this is doable.

         Again, I cite that proper QoS is really hard in a
         broadcast wireless medium, and that environmental
         noise (e.g. a microwave oven) makes it virtually
         impossible to do anything but very soft QoS.

     Document: The routing protocol SHOULD support walking
         speeds for maintaining network connectivity as the
         handheld device changes position in the wireless
         network.

     Comment: This is, interestingly, one of the very very
         few places that mobility is mentioned in ROLL
         documents. A lot of the other constraints above
         becomes orders of magnitude more complex (both
         realistically and theoretically) when things aren't
         static. I just note that most often the wg seems to
         respond with "Ohh, sensors are static, which is why
         we do not consider mobility as an important
         component in our protocol design". It's a good
         thing to have it there, but I am not sure that all
         the above can be solved with this present
         requirement.

     Comment: There're scattered security pieces in the
         document. The "limited ressources" that are assumed
         are worrying, considering the expectations that are
         put up, and considering the limited success we've
         had with rtg security in the past.  But, a
         SEC-AD/SECDIR may be better positioned to comment
         on that than I.

I agree with Tim's COMMENT about the explicit impact of security issues on a ROLL routing protocol.

More generally, the document might be improved by clearer and more explicit separation and identification of the industrial ROLL environment and the requirements derived from that environment for a ROLL protocol.  

For example, section 4.1 is titled "Service Parameters" (no mention of requirements), but it includes some RFC 2119 terminology requirements in the last two paragraphs.  Sections 5 through 9 all include requirements, but only some of them include "Requirements" in the title.

As I expect this document is mostly for the use of the roll WG in meeting its charter milestones, the fact that the roll WG has forwarded the document to us for publication implies that it meets their requirements.    So, I'm happy to accept the document as is if the WG finds it useful.

section 11. Security

s/Security/Security Considerations/

s/encrypted with unique/encrypted with statistically unique/

Section 11 also does not explore the implications of these security requirements for the
routing protocol itself.   This is a more serious omission, and I considered making this
a DISCUSS.  However, the roll wg has recently indicated that it was ready to begin work
on a security framework, and this topic can reasonably be addressed there.  I would suggest
adding a statement that "Implications of these security requirements for the routing protocol
itself are a topic for future work."