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

[Ballot discuss]
I liked the way the draft was written, and it provides an interesting
view into this application space. I think the picture it paints is fairly
accurate.

However, I am concerned that it tries to aim quite high in terms of
mandatory functionality, and does not really recognize the inherent
design tradeoffs that exist in this space. In addition, there are a
couple of specific issues.

But I think we can address all this easily with few specific changes,
and I'm hoping I get back from you some text proposals for these.

For the aim-high problem: I think it would be helpful if the document
contained a section or paragraph on conflicting requirements and
constraints, and explicitly noted that its possible that not all
requirements may be satisfiable simultaneously. Alternatively/in
addition I would consider renaming the requirements to goals or
something softer than MUST requirements.

The specific problems:

Problem 1

> The routing protocol SHOULD support broadcast or multicast
> addressing.

Please clarify whether you really mean OR. And since you seem
to be talking about IPv6, there are no broadcast addresses in
IPv6. Perhaps you can just say "SHOULD support multicast
addressing"?

Problem 2

> The routing protocol MUST route on paths that are changed to
> appropriately provision the application requirements.

This sentence is unclear. What does it mean?

Problem 3

> 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
> ...

What does "the route" refer to here? The full routing table? Some
specific route?

Aren't the first and the second sentences at odds with each other?
If you only recalculate when there's a change, what is the continuous
recalculation process?

Problem 4

The document is unclear with regards to how much it affects things
at the application layer. Some of the requirements seem to say
that routing must take application layer requirements into account,
the discussion on centralized communication might mean not just
routing config but also other types of configuration. I think we
need to look at this from an architectural point of view, and at
least my opinion is that separation of concerns is very valuable.
I do not mean to prohibit requirements that ensure the routing
protocol is suitable for these types of environments. But I think
routing protocols should operate on addresses and prefixes, as
opposed to application flows. And in particular, configuration
issues at application should not be dealt at that level.

[Ballot discuss]
I liked the way the draft was written, and it provides an interesting
view into this application space. I think the picture it paints is fairly
accurate.

However, I am concerned that it tries to aim quite high in terms of
mandatory functionality, and does not really recognize the inherent
design tradeoffs that exist in this space. In addition, there are a
couple of specific issues.

But I think we can address all this easily with few specific changes,
and I'm hoping I get back from you some text proposals for these.

For the aim-high problem: I think it would be helpful if the document
contained a section or paragraph on conflicting requirements and
constraints, and explicitly noted that its possible that not all
requirements may be satisfiable simultaneously. Alternatively/in
addition I would consider renaming the requirements to goals or
something softer than MUST requirements.

The specific problems:

Problem 1

> The routing protocol SHOULD support broadcast or multicast
> addressing.

Please clarify whether you really mean OR. And since you seem
to be talking about IPv6, there are no broadcast addresses in
IPv6. Perhaps you can just say "SHOULD support multicast
addressing"?

Problem 2

> The routing protocol MUST route on paths that are changed to
> appropriately provision the application requirements.

This sentence is unclear. What does it mean?

Problem 3

> 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
> ...

What does "the route" refer to here? The full routing table? Some
specific route?

Aren't the first and the second sentences at odds with each other?
If you only recalculate when there's a change, what is the continuous
recalculation process?

Problem 4

The document is unclear with regards to how much it affects things
at the application layer. Some of the requirements seem to say
that routing must take application layer requirements into account,
the discussion on centralized communication might mean not just
routing config but also other types of configuration. I think we
need to look at this from an architectural point of view, and at
least my opinion is that separation of concerns is very valuable.
I do not mean to prohibit requirements that ensure the routing
protocol is suitable for these types of environments. But I think
routing protocols should operate on addresses and prefixes, as
opposed to application flows. And in particular, configuration
issues at application should be dealt at that level.

[Ballot comment]
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.

[Ballot discuss]
I liked the way the draft was written, and it provides an interesting
view into this application space. I think the picture it paints is fairly
accurate.

However, I am concerned that it tries to aim quite high in terms of
mandatory functionality, and does not really recognize the inherent
design tradeoffs that exist in this space. In addition, there are a
couple of specific issues.

For the aim-high problem: I think it would be helpful if the document
contained a section or paragraph on conflicting requirements and
constraints, and explicitly noted that its possible that not all
requirements may be satisfiable simultaneously. Alternatively/in
addition I would consider renaming the requirements to goals or
something softer than MUST requirements.

The specific problems:

Problem 1

> The routing protocol SHOULD support broadcast or multicast
> addressing.

Please clarify whether you really mean OR. And since you seem
to be talking about IPv6, there are no broadcast addresses in
IPv6. Perhaps you can just say "SHOULD support multicast
addressing"?

Problem 2

> The routing protocol MUST route on paths that are changed to
> appropriately provision the application requirements.

This sentence is unclear. What does it mean?

Problem 3

> 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
> ...

What does "the route" refer to here? The full routing table? Some
specific route?

Aren't the first and the second sentences at odds with each other?
If you only recalculate when there's a change, what is the continuous
recalculation process?

Problem 4

The document is unclear with regards to how much it affects things
at the application layer. Some of the requirements seem to say
that routing must take application layer requirements into account,
the discussion on centralized communication might mean not just
routing config but also other types of configuration. I think we
need to look at this from an architectural point of view, and at
least my opinion is that separation of concerns is very valuable.
I do not mean to prohibit requirements that ensure the routing
protocol is suitable for these types of environments. But I think
routing protocols should operate on addresses and prefixes, as
opposed to application flows. And in particular, configuration
issues at application should be dealt at that level.

[Ballot discuss]
I liked the way the draft was written, and it provides an interesting
view into this application space. I think the picture it paints is fairly
accurate.

However, I am concerned that it tries to aim quite high in terms of
mandatory functionality, and does not really recognize the inherent
design tradeoffs that exist in this space. In addition, there are a
couple of specific issues.

For the aim-high problem: I think it would be helpful if the document
contained a section or paragraph on conflicting requirements and
constraints, and explicitly noted that its possible that not all
requirements may be satisfiable simultaneously. Alternatively/in
addition I would consider renaming the requirements to goals or
something softer than MUST requirements.

The specific problems:

> The routing protocol SHOULD support broadcast or multicast
> addressing.

Please clarify whether you really mean OR. And since you seem
to be talking about IPv6, there are no broadcast addresses in
IPv6. Perhaps you can just say "SHOULD support multicast
addressing"?

> The routing protocol MUST route on paths that are changed to
> appropriately provision the application requirements.

This sentence is unclear. What does it mean?

> 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
> ...

What does "the route" refer to here? The full routing table? Some
specific route?

Aren't the first and the second sentences at odds with each other?
If you only recalculate when there's a change, what is the continuous
recalculation process?

[Ballot comment]
Here's a solicited review from Thomas Clausen:

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.

[Ballot comment]
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.

[Ballot comment]
I think that this document does quite a good job of describing the requirements in a way that can be understood by a routing expert who is not knowledgeable in industrial networks. Thanks!

[Ballot comment]
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."

[Ballot discuss]
I salute the inclusion of the manageability section, and I would support the document, but I believe that the current paragraph that lists the requirements for manageability needs to be written in a more clear manner:

>  The routing protocol for LLNs is expected to be easy to deploy and
  manage.  Because the number of field devices in a network is large,
  provisioning the devices manually may not make sense.  The routing
  MAY require commissioning of information about the node itself, like
  identity, security tokens, radio standards and frequencies, etc.  The
  routing protocol SHOULD NOT require to preprovision information about
  the environment where the node will be deployed.  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.

Problems:

- it is not clear what 'routing MAY require commissioning of information about the node itself- - is this a requirement for the protocol to be able to transfer information about the nodes? which direction? does this need to be in-band or can the information be transfered out of the protocol?
- similar question about the last phrase. Previous text mentions that because of scalability reasons manual configuration of hosts is not practical. If so, how would 'distribution of configuration from a centralized management controller' be? Is this a requirement from the protocol, or for hosts to use other adequate management protocols?
- I was expecting also a requirement about how a 'new device will connect and report at the LLN access point'. There is no requirement about reporting or other forms or notifications.

[Ballot discuss]
I salute the inclusion of the manageability section, and I would support the document, but I believe that the current paragraph that lists the requirements for manageability needs to be written in a more clear manner:

>  The routing protocol for LLNs is expected to be easy to deploy and
  manage.  Because the number of field devices in a network is large,
  provisioning the devices manually may not make sense.  The routing
  MAY require commissioning of information about the node itself, like
  identity, security tokens, radio standards and frequencies, etc.  The
  routing protocol SHOULD NOT require to preprovision information about
  the environment where the node will be deployed.  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.

Priblems:

- it is not clear what 'routing MAY require commissioning of information about the node itself- - is this a requirement for the protocol to be able to transfer information about the nodes? which direction? does this need to be in-band or can the information be transfered out of the protocol?
- similar question about the last phrase. Previous text mentions that because of scalability reasons manual configuration of hosts is not practical. If so, how would 'distribution of configuration from a centralized management controller' be? Is this a requirement from the protocol, or for hosts to use other adequate management protocols?
- I was expecting also a requirement about how a 'new device will connect and report at the LLN access point'. There is no requirement about reporting or other forms or notifications.

[Note]: 'This I-D was updated after IETF last call to synchronise with IESG review comments made for draft-ietf-roll-urban-routing-reqs. It also pickes up GenArt review coments.' added by Adrian Farrel

Proto-write-up for draft-ietf-roll-indus-routing-reqs

Intended status : Informational Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

JP Vasseur is the document shepherd.
He has personally reviewed the document and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

The I-D has been discussed and reviewed by the Working group.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues with this document that the Responsible Area Director
>        and/or the IESG should be aware of?  For example, perhaps he
>        or she is uncomfortable with certain parts of the document, or
>        has concerns whether there really is a need for it.  In any
>        event, if the WG has discussed those issues and has indicated
>        that it still wishes to advance the document, detail those
>        concerns here.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  How solid is the WG consensus behind this document?  Does it
>        represent the strong concurrence of a few individuals, with
>        others being silent, or does the WG as a whole understand and
>        agree with it?

Good consensus.

> (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
>        discontent?  If so, please summarise the areas of conflict in
>        separate email messages to the Responsible Area Director.  (It
>        should be in a separate email because this questionnaire is
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

Checks have been made. No Errors.

> (1.h)  Has the document split its references into normative and
>        informative?  Are there normative references to documents that
>        are not ready for advancement or are otherwise in an unclear
>        state?  If such normative references exist, what is the
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split.
No downrefs.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

No IANA action.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  The IESG approval announcement includes a Document
>        Announcement Write-Up.  Please provide such a Document
>        Announcement Write-Up.  Recent examples can be found in the
>        "Action" announcements for approved documents.  The approval
>        announcement contains the following sections:
>
>        Technical Summary
>          Relevant content can frequently be found in the abstract
>          and/or introduction of the document.  If not, this may be
>          an indication that there are deficiencies in the abstract
>          or introduction.

    Wireless, low power field devices enable industrial users to
    significantly increase the amount of information collected and the
    number of control points that can be remotely managed.  The
    deployment of these wireless devices will significantly improve the
    productivity and safety of the plants while increasing the 
efficiency
    of the plant workers by extending the information set available from
    wired systems.  In an industrial environment, low power, high
    reliability, and easy installation and maintenance are mandatory
    qualities for wireless devices.  The aim of this document is to
    analyze the requirements for the routing protocol used for Low power
    and Lossy Networks (LLN) in industrial environments.
    IPv6 is perceived as a key technology to
    provide the scalability and interoperability that are required in
    that space and is being more and more present in standards and
    products under development and early deployments.

    Cable is perceived as a more proven, safer techhnology, and 
existing,
    operational deployments are very stable in time.  For these reasons,
    it is not expected that wireless will replace wire in any 
foreseeable
    future; the consensus in the industrial space is rather that 
wireless
    will tremendously augment the scope and benefits of automation by
    enabling the control of devices that were not connected in the past
    for reasons of cost and/or deployment complexities.  But for LLN to
    be adopted in the industrial environment, the wireless network needs
    to have three qualities: low power, high reliability, and easy
    installation and maintenance.  The routing protocol used for low
    power and lossy networks (LLN) is important to fulfilling these
    goals.

    Industrial automation is segmented into two distinct application
    spaces, known as "process" or "process control" and "discrete
    manufacturing" or "factory automation".  In industrial process
    control, the product is typically a fluid (oil, gas, chemicals ...).
    In factory automation or discrete manufacturing, the products are
    individual elements (screws, cars, dolls).  While there is some
    overlap of products and systems between these two segments, they are
    surprisingly separate communities.  The specifications targeting
    industrial process control tend to have more tolerance for network
    latency than what is needed for factory automation.

    Irrespective of this different 'process' and 'discrete' plant nature
    both plant types will have similar needs for automating the
    collection of data that used to be collected manually, or was not
    collected before.  Examples are wireless sensors that report the
    state of a fuse, report the state of a luminary, HVAC status, report
    vibration levels on pumps, report man-down, and so on.

    Other novel application arenas that equally apply to both 'process'
    and 'discrete' involve mobile sensors that roam in and out of 
plants,
    such as active sensor tags on containers or vehicles.

    Some if not all of these applications will need to be served by the
    same low power and lossy wireless network technology.  This may mean
    several disconnected, autonomous LLN networks connecting to multiple
    hosts, but sharing the same ether.  Interconnecting such networks, 
if
    only to supervise channel and priority allocations, or to fully
    synchronize, or to share path capacity within a set of physical
    network components may be desired, or may not be desired for
    practical reasons, such as e.g. cyber security concerns in relation
    to plant safety and integrity.

    All application spaces desire battery operated networks of hundreds
    of sensors and actuators communicating with LLN access points.  In 
an
    oil refinery, the total number of devices might exceed one million,
    but the devices will be clustered into smaller networks that in most
    cases interconnect and report to an existing plant network
    infrastructure.
>        Working Group Summary
>          Was there anything in WG process that is worth noting?  For
>          example, was there controversy about particular points or
>          were there decisions where the consensus was particularly
>          rough?

No controversy.

>        Document Quality
>          Are there existing implementations of the protocol?  Have a
>          significant number of vendors indicated their plan to
>          implement the specification?  Are there any reviewers that
>          merit special mention as having done a thorough review,
>          e.g., one that resulted in important changes or a
>          conclusion that the document had no substantive issues?  If
>          there was a MIB Doctor, Media Type or other expert review,
>          what was its course (briefly)?  In the case of a Media Type
>          review, on what date was the request posted?

The I-D is informational and specifies IPv6 routing requirements.