Subject: [Roll] Detailed Review of draft-ietf-roll-indus-routing-reqs

From: JP Vasseur <[email-masked]>
Date: Wed, 10 Sep 2008 16:01:28 +0200

Hi,

After the review of draft-ietf-roll-urban-routing-reqs and
draft-ietf-roll-home-routing-reqs (new revision coming soon according to
their authors), here is my review of draft-ietf-roll-indus-routing-reqs
(lots of excellent content).

1) Abstract and Section 2
      For wireless devices to have a significant
   advantage over wired devices in an industrial environment the
   wireless network needs to have three qualities: low power, high
   reliability, and easy installation and maintenance.

JP> I would propose not to ³oppose² wireless and wired devices. Indeed,
sensor networks will more than likely be interconnected by a variety of
links. Still those networks will be LLN and will require these three
qualities. I would then suggest to keep the list of qualities but generalize
it to devices in LLN.

2) s/L2N/LLN in the entire document (to match the ROLL charter).
I still owe the WG a terminology ID (will be done early next week).

3) I skip the terminology section since it will addressed in the terminology
ID. 

4) Introduction

Referring to:
³Wireless field devices enable expansion of networked points by
   appreciably reducing cost of installing a device.  The cost
   reductions come from eliminating cabling costs and simplified
   planning.  Cabling also carries an overhead cost associated with
   planning the installation, determining where the cable has to run,
   and interfacing with the various organizations required to coordinate
   its deployment.  Doing away with the network and power cables reduces
   the planning and administrative overhead of installing a device.²

JP> This is a bit arguable ... (look at PLC) and not really a technical
consideration. I would suggest to simply remove this paragraph.

5) Section 2

* ³wired HART² please add a informative reference.

6) s/²In the near future, most low power and lossy network systems will be
   for low frequency data collection.²/²In the near future, most low power
and lossy network systems in industrial automation environments will be
   for low frequency data collection.²

7) In several places, you make the assumption that the collected data is
sent to a Sink/... Residing outside of the LLN. Don¹t you see cases where
there will be intra-LLN flows in Industrial automation ?
And I just read: ³  In the future, it is envisioned that some open loop
processes will be
   automated (closed loop) and packets will flow over local loops and
   not involve the L2N access point. ³ - Thanks.

8) you wrote: ³More likely though is that loops will be closed in the field
   entirely, which in most cases eliminates the need for having wireless
   links within the control loop.²
Why does this eliminate the need for wireless links ?

9) ³L2N-ish² ... You may want to slighlty reword here ;-)

10) s/²maximum number of hops from two to twenty.²/²maximum number of hops
of twenty²

11) Section 2.2

You wrote: ³ The backbone is a high-speed infrastructure network that may
   interconnect multiple WSNs through backbone routers.  Infrastructure
   devices can be connected to the backbone.  A gateway / manager that
   interconnects the backbone to the plant network of the corporate
   network can be viewed as collapsing the backbone and the
   infrastructure devices into a single device that operates all the
   required logical roles.  The backbone is likely to become an
   important function of the industrial network.²

Although I do agree that this is a common architecture, you may want to
indicate that this is only one possible architecture.

12) Could you please use a coherent terminology throughout the document ?
L2N sensor, field devices, ... I¹ll try to write the terminology ID this
week, then thanks to align the terminology.

13) I found this section is bit out of the scope:

³This multiple domain multiple applications connectivity creates a
   significant challenge.  Many different applications will all share
   the same medium, the ether, within the fence, preferably sharing the
   same frequency bands, and preferably sharing the same protocols,
   preferably synchronized to optimize co-existence challenges, yet
   logically segregated to avoid creation of intolerable short cuts
   between existing wired domains.

   Given this challenge, L2N networks are best to be treated as all
   sitting on yet another segregated domain, segregated from all other
   wired domains where conventional security is organized by perimeter.
   Moving away from the traditional perimeter security mindset means
   moving towards stronger end-device identity authentication, so that
   L2N access points can split the various wireless data streams and
   interconnect back to the appropriate domain pending identity and
   trust established by the gateways in the authenticity of message
   originators.²

14) Question about Figure 1: it looks like we still do have to compute
routes within the LLN ?
Furthermore, thanks to mention that this is one of many potential
architectures. For example, in section 2.2.2 you wrote ³2.2.2.  Logical
Topologies

   Most of the traffic over the LLN is publish/subscribe of sensor data
   from the field device towards the backbone router or gateway that
   acts as the sink for the WSN.²

You may want to replace the backbone router/gateway by a sink to make the
statement more general and applicable to other topologies (without a
gateway, ...). The use of gateway is a bit dangerous here unless carefully
defined but we¹ll discuss terminology in a separate email.

15) Section 2.2.2: ³Since publishing the data is the raison d'etre for most
of the
   sensors, it makes sense to build proactively a set of default routes
   between the sensors and one or more backbone router and maintain
   those routes at all times.  Also, because of the lossy nature of the
   network, the routing in place should attempt to propose multiple
   forwarding solutions, building forwarding topologies in the form of
   Directed Acyclic Graphs oriented towards the sinks.²

Is it a requirement to be able to configure ³default routes?²
By ³multiple forwarding solutions² do you actually means ³multiple paths² ?

16) Comment on ³For these reasons, the ROLL routing infrastructure MUST be
able to
   compute and update constrained routes on demand (that is reactively),
   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.²

* you may want to move the MUST in the routing requirement sections, to have
them all in one place.
* Are you requiring a reactive mechanism

17) Section 3.
* ³Service Requirement² - You may want to change the title for ³Traffic
Characteristics² just to avoid confusion with upper layer requirements.
excellent paragraph
* I¹m not sure to see the rationale of the various bullets ³data bandwidth²,
³Latency², ... In this context of routing requirements.
* You wrote ³The routing protocol
   MUST be able to set up unidirectional or asymmetrical cost routes
   that are composed of one or more non congruent paths.²
You may want to reword this sentence, which may be misleading (in
particular, there is no ³or² routes can be unidirectional and
asymmetrical²). Did you mean ³The routing protocol MUST be able to compute a
set of unidirectional routes with potentially different costs².

18) Section 3.1

* S/ Time-varying user requirements for latency and bandwidth will require
   changes in the provisioning of the underlying L2 protocols/ Time-varying
user requirements for latency and bandwidth may require
   changes in the provisioning of the underlying L2 protocols.

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

JP> This should translate into ³The routing protocol MUST dynamically
recompute path if the underlying topology changes.

   ³The routing
   protocol MUST support the ability to recompute paths based on
   underlying link characteristics that may change dynamically.²

JP> Could you be more accurate ? ³What if the BER crosses some threshold?².
Should it trigger a path computation ? If so, you would need to list all
parameters that can trigger a path computation. Alternatively, (IMO the
prefered option) each of the link characteristic should be reflected in a
metric or attribute change that will trigger a path computation (use filters
of course). 

19) Section 3.2.
S/²The routing algorithm MUST be able to
   generate different routes for different flows.²/²The routing algorithm
MUST be able to
   generate different routes with different characteritics (e.g. Optimized
according to different cost, ...).²

20) Replace globally ³low power lossy network² by ³LLN².

21) Replace globally ³#² by ³number².

22) s/² 3)  Probability of failure on demand,²/² 3)  Probability of failure
to compute an on demand route²

23) In the list of ³Reliability Requirements² you may want to add a ³...²
since there are many other ones (ability to reroute upon a network failure,
...).

24) ³Hop-by-hop path diversity is used to improve latency-bounded
   reliability.²

JP> Path diversity does not help with latency-bounded reliability ... It
does help to increase packet delivery if you use a 1+1 technique, or to find
an alternate path or limit the proportion of flows impacted by a single
failure but not for latency. What did you mean ?

25) ³The routing protocol MUST support multiple L2N access
   points and load distribution among L2N access points.
JP> In order to make this requirement not ³topology dependent² could you
reword it ³The routing protocol MUST be able to compute paths towards
different destination so as to perform load balancing across a variety of
paths.²

26) ³The routing
   protocol MUST support multiple L2N access points when L2N access
   point redundancy is required.²

This is not a routing protocol requirement.

27) ³Because L2Ns are lossy in nature,
   multiple paths in a L2N route MUST be supported. ³ --> already stated.

28) Section 6:

³2)  Delivery of common packets to multiple routers over a backbone,
       where the packets results in each receiving router initiating
       multicast (sometimes as a full broadcast) within the LLN.  This
       is byproduct of having potentially physically separated backbone
       routers that can inject messages into different portions of the
       same larger LLN.²

JP> IMO a too solution-specific statement.

29) Section 7
* ³The routing algorithm SHOULD always be in the process of
   optimizing the system in response to changing link statistics.²
JP> The term ³optimizing² is worth a few words of explanation. Optimizing
with regards to which objective ?

* ³The
   routing algorithm MUST re-optimize the paths when field devices
   change due to insertion, removal or failure, and this re-optimization
   MUST not cause latencies greater than the specified constraints
   (typically seconds to minutes).²
Few comments here: (1) The first ³MUST² is not different than the basic
requirement of being able to compute new path upon topology changes. (2) I
would propose to carefully use the term ³re-optimization². Indeed, I guess
that you refer to the event where a ³shorter² path is found according to
some metrics. Then you are requiring the ability to switch to a shorter path
while bounding the latency, which requires to only switch if the delta
between the old and new cost is also bounded and also implies other
constraints. Indeed, in distributed systems, you cannot guarantee that
systems are fully synchronized. Thus a router may start using a route that
is not yet ready if some of the next hops have not converged yet, which may
lead to micro-loops. Could you elaborate on this requirement ?

30) 
* ³The routing protocol SHOULD support the wireless worker with fast
   network connection times of a few of seconds, and low command and
   response latencies to the plant behind the L2N access points, to
   applications, and to field devices.  ³

Is it a different requirement than the one expressed in Section 7:

³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 protocol SHOULD also
   support the bandwidth allocation for bulk transfers between the field
   device and the handheld device of the wireless worker.   ³

JP> of course, I see what you mean but this should either be removed or
reworded. This may simply refer to topology changes, for which you already
have a routing requirement or some cross-layer function (hope not).

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

   Some field devices will be mobile.  These devices may be located on
   moving parts such as rotating components or they may be located on
   vehicles such as cranes or fork lifts.  The routing protocol SHOULD
   support vehicular speeds of up to 35 kmph.
³

JP> You may just want to say that such requirement has also consequences on
non-routing functions.

31) Section 9

* ³Therefore,
   the routing protocol MUST support auto-provisioning of field devices.²

JP> To which extent ? Does that mean a true 0-configuration routing protocol
?

*²The protocol also MUST support the distribution of configuration from
   a centralized management controller if operator-initiated
   configuration change is allowed.²

JP> Not a routing requirement. Or do you refer to the dynamic set up of a
³default DAG/Tree² used to retrieve a more sophisticated ³routing feature²
from a centralized tool ?

32) Section 10

* s/²1) attacks on the actual application served be the wireless
   devices and ³/²1) attacks on the actual application served by the
wireless
   devices and ³

* ³2) attacks that exploit the presence of a wireless access
   point that MAY provide connectivity onto legacy wired plant networks,
   so attacks that have little to do with the wireless devices in the
   L2Ns. ³/²2) attacks that exploit the presence of a wireless access
   point that may provide connectivity onto legacy wired plant networks,
   so attacks that have little to do with the wireless devices in the
   LLNs. ³

* ³The routing protocol SHOULD place limited trust in the field devices
   deployed in the plant network.
³

JP> Could you elaborate a little bit ? It sounds a bit too vague for a
protocol designer to figure out what action to take according to this
requirement. 

³Standards exist that address those
   vulnerabilities.²

JP> ??

33) replace ³isn¹t by is not², ³doesn¹t by does not² , ...

Thanks.

Cheers,

JP.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Wed, 10 Sep 2008 17:23:31 +0200

Hi,

Two more things: 

1) Can you remove the following reference: draft-culler-rl2n-routing-reqs ?

2) idnits:
  Miscellaneous warnings:
  
----------------------------------------------------------------------------

  == Using lowercase 'not' together with uppercase 'MUST' is not an accepted
     usage according to RFC 2119.  Please use 'MUST NOT' (if that is what
you
     mean).
     
     Found 'MUST not' in this paragraph:
     
     Network connectivity in real deployments is always time varying,
     with time constants from seconds to months.  So long as the underlying
     connectivity has not been compromised, this link churn should not
     substantially affect network operation.  The routing algorithm MUST
     respond to normal link failure rates with routes that meet the Service
     requirements (especially latency) throughout the routing response.  The
     routing algorithm SHOULD always be in the process of optimizing the
     system in response to changing link statistics.  The routing algorithm
     MUST re-optimize the paths when field devices change due to insertion,
     removal or failure, and this re-optimization MUST not cause latencies
     greater than the specified constraints (typically seconds to minutes).

  Checking references for intended status: Informational
  
----------------------------------------------------------------------------

  == Missing Reference: 'HART' is mentioned on line 1003, but not
     defined
     '[HART]     www.hartcomm.org, "Highway Addressable Remote Transduc...'

  == Unused Reference: 'I-D.culler-rl2n-routing-reqs' is defined on line
995,
     but no explicit reference was found in the
     text
     '[I-D.culler-rl2n-routing-reqs] Vasseur, J. and D. Cullerot,
"Routing...'

Thanks.

JP.

On 9/10/08 4:01 PM, "JP Vasseur" <[email-masked]> wrote:

> draft-ietf-roll-home-routing-reqs (new revision coming soon according to their
> authors), here is my review of draft-ietf-roll-indus-routing-reqs (lots of
> excellent content).
> 
> JP> I would propose not to ³oppose² wireless and wired devices. Indeed, sensor
> networks will more than likely be interconnected by a variety of links. Still
> those networks will be LLN and will require these three qualities. I would
> then suggest to keep the list of qualities but generalize it to devices in
> LLN.
> 
> 
>    for low frequency data collection.²/²In the near future, most low power and
> lossy network systems in industrial automation environments will be
> 7) In several places, you make the assumption that the collected data is sent
> to a Sink/... Residing outside of the LLN. Don¹t you see cases where there
> will be intra-LLN flows in Industrial automation ?
> 10) s/²maximum number of hops from two to twenty.²/²maximum number of hops of
> twenty²
> 
> 11) Section 2.2
> 
> 12) Could you please use a coherent terminology throughout the document ? L2N
> sensor, field devices, ... I¹ll try to write the terminology ID this week,
> then thanks to align the terminology.
> 
> 14) Question about Figure 1: it looks like we still do have to compute routes
> within the LLN ?
> statement more general and applicable to other topologies (without a gateway,
> ...). The use of gateway is a bit dangerous here unless carefully defined but
> we¹ll discuss terminology in a separate email.
> 
> 15) Section 2.2.2: ³Since publishing the data is the raison d'etre for most of
> the
> You may want to reword this sentence, which may be misleading (in particular,
> there is no ³or² routes can be unidirectional and asymmetrical²). Did you mean
> ³The routing protocol MUST be able to compute a set of unidirectional routes
> with potentially different costs².
> 
> 18) Section 3.1
> 
>    generate different routes for different flows.²/²The routing algorithm MUST
> be able to
> 22) s/² 3)  Probability of failure on demand,²/² 3)  Probability of failure to
> compute an on demand route²
> 
> JP> Path diversity does not help with latency-bounded reliability ... It does
> help to increase packet delivery if you use a 1+1 technique, or to find an
> alternate path or limit the proportion of flows impacted by a single failure
> but not for latency. What did you mean ?
> 
> JP> The term ³optimizing² is worth a few words of explanation. Optimizing with
> regards to which objective ?
> 
> * ³The
> that you refer to the event where a ³shorter² path is found according to some
> metrics. Then you are requiring the ability to switch to a shorter path while
> bounding the latency, which requires to only switch if the delta between the
> old and new cost is also bounded and also implies other constraints. Indeed,
> in distributed systems, you cannot guarantee that systems are fully
> synchronized. Thus a router may start using a route that is not yet ready if
> some of the next hops have not converged yet, which may lead to micro-loops.
> Could you elaborate on this requirement ?
> 
> 30) 
> JP> To which extent ? Does that mean a true 0-configuration routing protocol ?
> 
>    devices and ³/²1) attacks on the actual application served by the wireless
>    devices and ³
>

---

From: Kris Pister <[email-masked]>
Date: Sat, 27 Sep 2008 14:02:35 -0700

JP - good comments, thanks.  We'll incorporate/address most of these.
I have a few questions and comments below.

ksjp

JP Vasseur wrote:
> draft-ietf-roll-home-routing-reqs (new revision coming soon according 
> to their authors), here is my review of 
> draft-ietf-roll-indus-routing-reqs (lots of excellent content).
>
> JP> I would propose not to "oppose" wireless and wired devices. 
> Indeed, sensor networks will more than likely be interconnected by a 
> variety of links. Still those networks will be LLN and will require 
> these three qualities. I would then suggest to keep the list of 
> qualities but generalize it to devices in LLN.
>
>
> 3) I skip the terminology section since it will addressed in the 
> terminology ID.
>
> 4) Introduction
>
> Referring to:
> "Wireless field devices enable expansion of networked points by
>    the planning and administrative overhead of installing a device."
>
> JP> This is a bit arguable ... (look at PLC) and not really a 
> technical consideration. I would suggest to simply remove this paragraph.
Maybe we should have the argument :)  Can you elaborate on your thinking?
>
> 5) Section 2
>
> * "wired HART" please add a informative reference.
>
> 6) s/"In the near future, most low power and lossy network systems will be
>    for low frequency data collection."/"In the near future, most low 
> power and lossy network systems in industrial automation environments 
> will be
>    for low frequency data collection."
>
> 7) In several places, you make the assumption that the collected data 
> is sent to a Sink/... Residing outside of the LLN. Don't you see cases 
> where there will be intra-LLN flows in Industrial automation ?
> And I just read: "  In the future, it is envisioned that some open 
> loop processes will be
>    not involve the L2N access point. " - Thanks.
>
> 8) you wrote: "More likely though is that loops will be closed in the 
> field
>    links within the control loop."
> 9) "L2N-ish" ... You may want to slighlty reword here ;-)
>
> 10) s/"maximum number of hops from two to twenty."/"maximum number of 
> hops of twenty"
>
> 11) Section 2.2
>
> You wrote: " The backbone is a high-speed infrastructure network that may
>    important function of the industrial network."
>
> Although I do agree that this is a common architecture, you may want 
> to indicate that this is only *one* possible architecture.
>
> 12) Could you please use a coherent terminology throughout the 
> document ? L2N sensor, field devices, ... I'll try to write the 
> terminology ID this week, then thanks to align the terminology.
>
> "This multiple domain multiple applications connectivity creates a
>    originators."
Actually, I think that this is one of the critical hard problems for the 
IETF in general, and some
future re-chartered RoLL in particular, to solve in sensor networks.  
I'll work with Sicco to make
this clearer, but the main point here is that routing in industrial 
automation (at least) is not just
a question of populating look-up tables.  If mote A has a packet for 
mote Z, that packet may take
a very different path through the network depending on the application 
and QoS constraints.
Maybe B is the shortest path from A to Z, and certain packets do flow 
from A to B to Z, but
other packets do not have: 1) the right security; 2) the right priority; 
3) the right application
type; 4) the same QoS contract.
The routing algorithm must take into account both the QoS requirements 
coming down from
L4, and the link constraints coming up from L2.
> architectures. For example, in section 2.2.2 you wrote "2.2.2. 
>  Logical Topologies
>
>    acts as the sink for the WSN."
>
> You may want to replace the backbone router/gateway by a sink to make 
> the statement more general and applicable to other topologies (without 
> a gateway, ...). The use of gateway is a bit dangerous here unless 
> carefully defined but we'll discuss terminology in a separate email.
>
> 15) Section 2.2.2: "Since publishing the data is the raison d'etre for 
> most of the
>    Directed Acyclic Graphs oriented towards the sinks."
>
> Is it a requirement to be able to configure "default routes?"
> By "multiple forwarding solutions" do you actually means "multiple 
> paths" ?
>
> 16) Comment on "For these reasons, the ROLL routing infrastructure 
> MUST be able to
>    device to Infrastructure devices over time."
>
>     * you may want to move the MUST in the routing requirement
>       sections, to have them all in one place.
> * "Service Requirement" - You may want to change the title for 
> "Traffic Characteristics" just to avoid confusion with upper layer 
> requirements. *excellent paragraph
> ** I'm not sure to see the rationale of the various bullets "data 
> bandwidth", "Latency", ... In this context of routing requirements.
> * You wrote "The routing protocol
>    that are composed of one or more non congruent paths."
> particular, there is no "or" routes can be unidirectional and 
> asymmetrical"). Did you mean "The routing protocol MUST be able to 
> compute a set of unidirectional routes with potentially different costs".
>
> 18) Section 3.1
>
>    changes in the provisioning of the underlying L2 protocols/ 
> Time-varying user requirements for latency and bandwidth may require
> *  "The routing protocol MUST route on paths that are changed to
>    appropriately provision the application requirements."  
>
> JP> This should translate into "The routing protocol MUST dynamically 
No, I think that you're missing the point.  Say I currently have a route 
from A->B->Z that is provisioned to handle 1 packet every 5 seconds.  
There are other routes, e.g. A->C->Z that are known to exist, but are 
not used.  Then A requests 100 times more bandwidth, and B announces 
that it can handle twice the bandwidth, but anything more would violate 
it's energy-scavenging-limited power restrictions.  This triggers both a 
need to generate new routes, and to update a bunch of L2 provisioning.  
You could try to auto-detect-and-provision on L2, but if the service 
request is based on latency instead of BW, then there is no way for L2 
to figure that out by itself.  Solving the routing problem without some 
information exchange with L2 is not possible.
>    "The routing
>    underlying link characteristics that may change dynamically."
>
> JP> Could you be more accurate ? "What if the BER crosses some 
> threshold?". Should it trigger a path computation ? If so, you would 
> need to list all parameters that can trigger a path computation. 
> Alternatively, (IMO the prefered option) each of the link 
> characteristic should be reflected in a metric or attribute change 
> that will trigger a path computation (use filters of course).
I'm not sure that I understand.  If I change "link characteristics" to 
"link metrics" does that fix it?
>
> 19) Section 3.2.
> S/"The routing algorithm MUST be able to
>    generate different routes for different flows."/"The routing 
> algorithm MUST be able to
>    generate different routes with different characteritics (e.g. 
> Optimized according to different cost, ...)."
>
> 20) Replace globally "low power lossy network" by "LLN".
>
> 21) Replace globally "#" by "number".
>
> 22) s/" 3)  Probability of failure on demand,"/" 3)  Probability of 
> failure to compute an on demand route"
>
> 23) In the list of "Reliability Requirements" you may want to add a 
> "..." since there are many other ones (ability to reroute upon a 
> network failure, ...).
>
> 24) "Hop-by-hop path diversity is used to improve latency-bounded
>    reliability."
>
> JP> Path diversity does not help with latency-bounded reliability ... 
> It does help to increase packet delivery if you use a 1+1 technique, 
> or to find an alternate path or limit the proportion of flows impacted 
> by a single failure but not for latency. What did you mean ?
Path diversity *does* help with latency-bounded reliability, and I have 
volumes of data to prove it.  In LLNs the PDR on individual links can 
very rapidly change by many tens of percent, up to and including a 
sudden transition from near 100% to 0%.  If I have a 1s latency target 
for 99.9% of my packets, a substantial change in PDR needs to initiate 
new path computation, but I can't afford to wait around for the results 
of that effort - I need another path right now.  And that other path 
can't be something that I created as a backup yesterday and haven't used 
recently.  It needs to be exercised regularly so that I know that I can 
trust it.
>
> 25) "The routing protocol MUST support multiple L2N access
> JP> In order to make this requirement not "topology dependent" could 
> you reword it "The routing protocol MUST be able to compute paths 
> towards different destination so as to perform load balancing across a 
> variety of paths."
Hmm.  What if the destination is a control system on the (not LLN) plant 
network, and I have a choice of many different APs?  I guess that the 
diversity requirement in 24) is enough.
> 26) "The routing
>    point redundancy is required."
>
> 27) "Because L2Ns are lossy in nature,
>    multiple paths in a L2N route MUST be supported. " --> already stated.
>
> 28) Section 6:
>
> "2)  Delivery of common packets to multiple routers over a backbone,
>        same larger LLN."
> * "The routing algorithm SHOULD always be in the process of
>    optimizing the system in response to changing link statistics."
> JP> The term "optimizing" is worth a few words of explanation. 
> Optimizing with regards to which objective ?
>
> * "The
>    (typically seconds to minutes)."
> Few comments here: (1) The first "MUST" is not different than the 
> basic requirement of being able to compute new path upon topology 
> changes. (2) I would propose to carefully use the term 
> "re-optimization". Indeed, I guess that you refer to the event where a 
> "shorter" path is found according to some metrics. Then you are 
> requiring the ability to switch to a shorter path while bounding the 
> latency, which requires to only switch if the delta between the old 
> and new cost is also bounded and also implies other constraints. 
> Indeed, in distributed systems, you cannot guarantee that systems are 
> fully synchronized. Thus a router may start using a route that is not 
> yet ready if some of the next hops have not converged yet, which may 
> * "The routing protocol SHOULD support the wireless worker with fast
>    applications, and to field devices.  "
>
> "The routing algorithm MUST find the appropriate
>    SHOULD report success or failure within tens of seconds."
>
>
> * "The routing protocol SHOULD also
>    device and the handheld device of the wireless worker.   "
>
> JP> of course, I see what you mean but this should either be removed 
> or reworded. This may simply refer to topology changes, for which you 
> already have a routing requirement or some cross-layer function (hope 
> not).
>
> "The routing
> "
> JP> You may just want to say that such requirement has also 
> consequences on non-routing functions.
Can you elaborate on this last line?
>
> 31) Section 9
>
> * "Therefore,
>    the routing protocol MUST support auto-provisioning of field devices."
>
If by "true 0-configuration" you mean that someone who knows nothing 
about networking can bolt 10 pressure sensors onto an oil well head and 
not have to do anything else to get them to work, then yes.
>
> *"The protocol also MUST support the distribution of configuration from
>    configuration change is allowed."
>
> JP> Not a routing requirement. Or do you refer to the dynamic set up 
> of a "default DAG/Tree" used to retrieve a more sophisticated "routing 
> feature" from a centralized tool ?
Definitely not a default DAG.  Sicco?
>
> 32) Section 10
>
> * s/"1) attacks on the actual application served be the wireless
>    devices and "/"1) attacks on the actual application served by the 
> wireless
>    devices and "
>
> * "2) attacks that exploit the presence of a wireless access
>    L2Ns. "/"2) attacks that exploit the presence of a wireless access
>    LLNs. "
> * "The routing protocol SHOULD place limited trust in the field devices
> "
> "Standards exist that address those
>    vulnerabilities."
>
> JP> ??
>
> 33) replace "isn't by is not", "doesn't by does not" , ...
>
> Thanks.
>
> Cheers,
>
> JP.