Subject: [Roll] Review of draft-ietf-roll-urban-routing-reqs-01

From: JP Vasseur <[email-masked]>
Date: Thu, 21 Aug 2008 21:28:54 +0200

Dear WG,

As discussed in Dublin, the plan is to try to Last Call all the
application-specific routing requirements document before end of September.
Thus, please provide your detailed comments as soon as possible.

Let me start my co-chair review with the Urban WSNs Routing Requirements,
since (with the exception of the Mobility issue) the document is fairly
stable. Comments are not by order of importance by in chronological order.

Abstract
#######
s/ for a wireless ROLL solution to be useful the protocol(s) ought to be
energy-efficient, scalable, and autonomous/ the routing solution ought to be
energy-efficient, scalable and autonomous.

JP> You may want to use a different word than ³Autonomous². Do you refer to
the ³self configuration² property ?

Section 1
#######
* ³Section 6 discusses the routing requirements for networks comprising
   such constrained devices in a U-LLN environment.  These requirements
   may be overlapping requirements derived from other application-
   specific requirements documents or as listed in
   [I-D.culler-rl2n-routing-reqs].²

JP> Please remove this reference (ID abandoned) and insert reference to
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.txt
, 
http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.tx
t and 
http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-r
eqs-00.txt.

* s/ Section 7 provides an overview of security considerations/ Section 7
provides an overview of routing security considerations

Section 2
########

* S/ ROLL: Routing over Low power and Lossy networks/ ROLL: Routing Over Low
power and Lossy networks

* Schedule:  An agreed execution, wake-up, transmission, reception,
         etc., time-table between two or more field devices.
The definition is a little bit too vague. If used in the generic sense, no
need to add it to the terminology section. Otherwise, it ought to be more
specific.

Section 3.1.1
###########
* S/ pre- planned location/ pre-planned location

* What you refer to as a repeater is in fact a router. What I would suggest
here is to reword this paragraph to indicate that some nodes are simple
routers whereas other nodes are routers and also perform sensing/actuating
task. Insert this paragraph after the Actuators and Sensors paragraphs.

* ³Actuators may generally be mobile but are likely to be static in the
majority of near-future roll-outs²: seems a bit contradictory. Don¹t you
want to simply say that in a near-future the majority will be static?

* ³Similar to the access points, actuator nodes do not suffer from any
long-term resource constraints.² what about battery-operated actuators ?

Section 3.1.4
###########
* ³pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
 heavy metals (e.g.  Mercury), pH, radioactivity, etc;² => please expand
acronym when first used.

* ³These meters will be capable of
   advanced sensing functionalities such as measuring quality of
   service, providing granular interval data, or automating the
   detection of alarm conditions.²
You may want to more accurately define the term ³quality of service² since
as you know, we used that term of other purposes in IETF documents.

* In addition they may be capable of
   advanced interactive functionalities such as remote service
   disconnect or remote demand reset.² => in this case, they are also acting
as actuators.

Section 3.2 
#########

* s/ between one other/between each other

* ³The network MUST be capable of supporting the organization of
   a large number of sensing nodes into regions containing on the order
   of 10^2 to 10^4 sensing nodes each.²
JP> Thanks to make this ³MUST² routing-specific and move it to the
requirements section.

Section 3.3
#########

* RFID: expand acronym (Radio Frequency IDentification) and add to the
terminology section

* s/battery-powered nodes/battery powered nodes
³Sensor nodes are capable of forwarding data.² In other words, they can act
as routers. No need to repeat this here.

Section 3.4
#########

* ³2.  packet errors due to medium access control;² JP> It is not really
³packet error² here.

* Some available protocols may cause packets of neighbouring nodes to
collide and hence cause a link outage.² JP> You may want to be more specific
³Some² ?

* ³if ISM bands are to be used.  For instance, if the 2.4GHz ISM band is
   used to facilitate communication between U-LLN nodes, then heavily
   loaded WLAN hot-spots become a detrimental performance factor
   jeopardizing the functioning of the U-LLN.²
JP> Please expand acronym when first used and add to the terminology section
(ISM, WLAN, ...)

* Don¹t you want to say a few words about the varying BER leading to
potentially even higher packet error loss ratio?

Section 4.1
#########

* ³Pre-programmed MAC²: expand acronym

* ³the autonomous organization² => self-organizing?

* ³For example, nodes in urban sensor nodes SHOULD be able to:² => Several
of the requirements that follow are nor routing specific. You may either
want to change the SHOULD for a ³should² or just focus on the routing
aspects and move them to the routing requirements section.

* ³o  Dynamically compute, select and possibly optimize the (multiple)
      path(s) that will be used by the participating devices to forward
      the traffic towards the actuators and/or the access point
      according to the service-specific and traffic-specific QoS,
      traffic engineering and security policies that will have to be
      enforced at the scale of a routing domain (that is, a set of
      networking devices administered by a globally unique entity), or a
      region of such domain (e.g. a metropolitan area composed of
      clusters of sensors).²
JP> You list important and stringent requirements here. Do you really need a
routing algorithms capable of computing a path on a per QoS/service
specific/... Basis ?

Section 4.2
#########

* ³After the initialization phase and possibly some operational time,
   new nodes may be injected into the network as well as existing nodes
   removed from the network.  The former might be because a removed node
   is replaced or denser readings/actuations are needed or routing
   protocols report connectivity problems. ³
JP> Just to avoid any mis-interpretation when referring to routing problem,
you mean that it may be desirable to inject to node because connectivity is
not sufficient (lack of enough redundant path, ...) and not because of a
routing issue per say.

* ³Differentiation
   SHOULD be made between node disappearance, where the node disappears
   without prior notification, and user or node-initiated disassociation
   ("phased-out"), where the node has enough time to inform the network
   about its removal.²
JP> Again this is not a routing requirement. Unless you refer to the ability
for the routing protocol to advertise to the rest of the network that it
will be removed in order for the other node to re-compute their path and
avoid traffic disruption (e.g. Similarly to what we do with the ISIS
overload bit for example.) Is it what you mean ? If so, please clarify and
move the routing requirement (SHOULD in capital letter to the routing
requirement section).

* ³The protocol(s) hence SHOULD support the pinpointing of problematic
routing areas²
JP> Could you clarify what you mean by ³pinpointing² since it could be
interpreted in many ways?

* The following section also requires some clarification  you wrote:
³Furthermore, to inform the
   access point(s) of the node's arrival and association with the
   network as well as freshly associated nodes about packet forwarding
   schedules, roles, etc, appropriate (link state) updating mechanisms
   SHOULD be supported.²
JP> Are you explicitly requiring a Link State routing protocol or a routing
protocol that provides information about link states or ... ?
Note that a requirement document should stay solution agnostic and stay
focus on the requirement. Is you requirement that any node needs to have
visibility on other node characteristics with no attempt of aggregation?

Section 4.3
#########

* ³The protocol(s) hence MUST support a large number of highly
   directional unicast flows from the sensing nodes or sensing clusters
   towards the access point or highly directed multicast or anycast
   flows from the nodes towards multiple access points.²
JP> I think that what you mean is that the routing protocol MUST be
optimized for Multipoint-to-Point traffic patterns (from sensors/actuators
to Sink). As written, it is not clear whether you refer to it as a routing
requirement ?
This in fact what you wrote in section 6.5: ³To this end, the routing
protocol(s) SHOULD support and utilize the fact of highly directed traffic
flow to facilitate scalability and parameter constrained routing.²

* s/ More generally, entire routing areas may be avoided at e.g. night but
heavily used during the day when nodes are scavenging from sunlight/ More
generally, entire routing areas may be avoided (e.g. at night) but heavily
used during the day when nodes are scavenging from sunlight.
JP> Doesn¹t this translate to the requirement for time-based routing (some
form of policy routing) ?

Section 4.4
#########

³However, they are not very stringent where
   latencies SHOULD simply be sufficiently smaller than typical
   reporting intervals²
JP> This is certainly true but not a routing requirement but a data plane
requirement unless you refer to the ability to support QoS aware routing
where each node may want to be able to compute different paths depending on
the traffic requirements?

* Move ³U-LLN network devices SHOULD support unicast and multicast routing
capabilities² to the routing requirement section. You may want to leave the
sentence here (without a SHOULD).

* You use the term ³anycast² that has been discussed in the past, in
particular in the context of the Home routing requirement document. I would
suggest to define this term in the document, refer to RFC4291 or RFC1546,
...

Section 4.5
#########

* ³An alarm is likely being
   registered by a plurality of sensing nodes where the delivery of a
   single alert message with its location of origin suffices in most
   cases.²
Then you provide the example of toxic gas level. This is one example where
it might be desirable not to perform data aggregation/fusion and get
multiple copies of the same message from different source to perform
³triangulation² and better localize the incident.

* ³Routing within urban sensor networks SHOULD require the U-LLN nodes
   to dynamically compute, select and install different paths towards a
   same destination, depending on the nature of the traffic.  From this
   perspective, such nodes SHOULD inspect the contents of traffic
   payload for making routing and forwarding decisions:

JP> This clarifies my previous question; you do refer to ability to compute
different paths (with different characteristic). Note that the path
selection process performed by the sender and potentially routers along the
path is not strictly speaking a routing requirement.
Move this requirement to the requirement section.

* ³for example, the analysis of the traffic payload SHOULD be derived into
aggregation
   capabilities for the sake of forwarding efficiency.²
JP> Can you clarify what you mean here?

* ³Delays and latencies are
   important; however, again, deliveries within seconds SHOULD suffice
   in most of the cases.²
JP> Clearly not a routing requirement!

Section 5
########

* ³The network SHOULD take into consideration that different application
   traffic may require different priorities when traversing the network,
   and that some traffic may be more sensitive to latency.²
JP> If by priorities you mean different routes with different
characteristics then this is fine and already covered. If you refer to
packet marking to provide different QoS in the data plane, this is not a
routing requirement.

* ³An U-LLN SHOULD support occasional large scale traffic flows from
   sensing nodes to access points, such as system-wide alerts. ³ and ³A node
MUST be able to send its own alerts toward an access
   point while continuing to forward traffic on behalf of other devices
   who are also experiencing an alert condition.  The network MUST be
   able to manage this sudden large traffic flow.²
JP> Not routing requirements. Unless ... You require the ability to compute
multiple paths and use all of them (symmetrical or asymmetrical routing ???)
to spread out the traffic and limit network delays ?

* You make an interesting reference to Smart Grid and DR/DSM. That said, you
wrote ³The network SHOULD support internetworking, while giving attention to
security implications of interfacing, for example, a home network with a
utility U-LLN.²
JP> Don¹t you mean that the routing protocol must be able to potentially
interact via potential route redistribution with other routing protocol used
in the Internet, should these two protocols not be identical ?

Section 6
#########

* S/Current urban roll-outs are composed of sometimes more than a hundred
nodes/ Current urban roll-outs are composed of sometimes more than one
hundred nodes

* ³ The routing protocols(s) SHOULD support the organization of a large
number of nodes into regions of to-be-specified size.²
JP> It will be difficult (or too easy ;-)) to be compliant with that SHOULD
with a to-be-specified size. Or did you mean ³configurable² ?

* ³To this end, the routing protocol(s) MUST support parameter
   constrained routing, where examples of such parameters (CPU, memory
   size, battery level, etc.) have been given in the previous paragraph.²
JP> Please use the term ³node constrained based routing²

* ³For the latter, the protocol(s) MUST support multi- and
   any-cast addressing.  The protocol(s) SHOULD also support the
   formation and identification of groups of field devices in the
   network.²
JP> You may want to more accurately define the term ³anycast²

* ³ To mandate fully interoperable implementations, the routing
   protocol(s) proposed in U-LLN MUST support different devices and
   underlying technologies without compromising the operability and
   energy efficiency of the network.²
JP> This requires clarification here. Do you mean that the routing protocol
MUST support node constrained based routing? If so, it is already stated
above. The support of different L1/L2 is a given (route over).

* Section 6.8, as written, is not related to routing but data plane. Let me
be more specific:

* ³To this end, the routing protocol(s) SHOULD support minimum latency
   for alert reporting and time-critical data queries.²
JP> The support of minimum latency path (data plane !) or the support for
different metric path (control plane) ?

* ³For regular data
   reporting, it SHOULD support latencies not exceeding a fraction of
   the smallest reporting interval.  ³
JP> Not a routing requirement. Even if you are referring to a bound on the
total path metric (the metric reflecting the delay in this case), this is an
implementation issue.

* ³Due to the different latency requirements, the routing protocol(s) SHOULD
support the ability of dealing with different latency requirements.  The
routing protocol(s) SHOULD also support the ability to route according to
different metrics (one of which could e.g. be latency).²
JP> yes these are routing requirements although I would suggest to remove
the first sentence, the requirement being captured in the second sentence.

Section 7
#########

* ³As every network, U-LLNs are exposed to security threats that MUST be
addressed.²
JP> You cannot put a MUST here unless you list the routing security threats.

* s/ potential security threats/ potential routing security threats => JP>
Please use the term ³routing security² in place of ³security² throughout the
section. 

* ³U-LLN networks SHOULD support mechanisms to preserve the
   confidentiality of the traffic that they forward.  The U-LLN network
   SHOULD NOT prevent an application from employing additional
   confidentiality mechanisms.²
JP> I do agree with the requirement but this is not a routing requirement.
Could you focus on the routing security issues ? Or are you referring to the
routing traffic confidentiality ? This is what you do right after:
³ The U-LLN MUST be protected against attempts to inject false or
   modified packets.  For example, an attacker SHOULD be prevented from
   manipulating or disabling the routing function by compromising
   routing update messages.  Moreover, it SHOULD NOT be possible to
   coerce the network into routing packets which have been modified in
   transit.  To this end the routing protocol(s) MUST support message
   integrity.²
JP> I do not see any reference to the type of routing attacks that could be
performed on such networks because of the typical P2MP traffic pattern,
extensive use of wireless links, ...
JP> What I would suggest is to re-focus on the routing security issues with
the Security expert that will get appointed.

Reference section
###############

The current reference section reads:
11.2.  Informative References

   [I-D.brandt-roll-home-routing-reqs]
              Brandt, A., "Home Automation Routing Requirement in Low
              Power and Lossy Networks",
              draft-brandt-roll-home-routing-reqs-01 (work in progress),
              May 2008.

JP> Please update to draft-ietf-roll-home-routing-reqs and add the reference
to draft-ietf-roll-indus-routing-reqs

   [I-D.culler-rl2n-routing-reqs]
              Vasseur, J. and D. Cullerot, "Routing Requirements for Low
              Power And Lossy Networks",
              draft-culler-rl2n-routing-reqs-01 (work in progress),
              July 2007.

JP> This one can be removed.

Last comment: please check that you expand acronyms when first used.

Thanks.

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

---

From: <[email-masked]>
Date: Thu, 21 Aug 2008 23:01:59 +0200

Dear all,
 
Thanks to Jean-Philippe for this thorough review. Please find a first
shot of personal comments inline, but I'll let my fellow co-authors
further elaborate accordingly.

	[CJ] [snip] 
	Abstract
	#######
	s/ for a wireless ROLL solution to be useful the protocol(s)
ought to be energy-efficient, scalable, and autonomous/ the routing
solution ought to be energy-efficient, scalable and autonomous.
	
	JP> You may want to use a different word than "Autonomous". Do
you refer to the "self configuration" property ?
	[CJ] We chose "autonomous" because it was generic enough, while
I think "self configuration" is too restrictive: it's not only a matter
of configuration, it's also a matter of making (forwarding) decisions,
self-healing capabilities, etc. Another word I would suggest is
"self-organizing", if this is more specific. 
	
	Section 1
	#######
	* "Section 6 discusses the routing requirements for networks
comprising
	   such constrained devices in a U-LLN environment.  These
requirements
	   may be overlapping requirements derived from other
application-
	   specific requirements documents or as listed in
	   [I-D.culler-rl2n-routing-reqs]."
	
	JP> Please remove this reference (ID abandoned) and insert
reference to
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02
.txt
<http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-0
2.txt> ,
http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-0
1.txt
<http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-
01.txt>  and
http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routi
ng-reqs-00.txt
<http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-rout
ing-reqs-00.txt> .
	[CJ] OK. 
	
	* s/ Section 7 provides an overview of security considerations/
Section 7 provides an overview of routing security considerations 
	[CJ] OK. 
	
	Section 2
	########
	
	* S/ ROLL: Routing over Low power and Lossy networks/ ROLL:
Routing Over Low power and Lossy networks
	[CJ] OK. 
	
	* Schedule:  An agreed execution, wake-up, transmission,
reception,
	         etc., time-table between two or more field devices.
	The definition is a little bit too vague. If used in the generic
sense, no need to add it to the terminology section. Otherwise, it ought
to be more specific.
	[CJ] Schedule is indeed very generic, but I think the sue of the
word makes perfect sense in the context of U-WSN networks. Being more
specific would mean elaborating on use cases where schedule information
is taken into account by field devices to perform some specific action.
If this proposal makes sense, I'm not sure the terminology section is
appropriate for such elaboration and would therefore suggest we (1) keep
the "schedule" definition in this section and (2) further elaborate on a
use case that illustrates the use of schedule information in section 5
of the draft. 
	
	Section 3.1.1
	###########
	[CJ] OK. 
	
	* What you refer to as a repeater is in fact a router. What I
would suggest here is to reword this paragraph to indicate that some
nodes are simple routers whereas other nodes are routers and lso perform
sensing/actuating task. Insert this paragraph after the Actuators and
Sensors paragraphs.
	[CJ] So you're suggesting to (1) remove section 3.1.2 (not
3.1.1, actually), and (2) indicate that some nodes are routers (not
"simple", btw :-), others also perform sensing/actuating tasks, right?
I'm fine with this suggestion, but I'd like to hear the feedback from my
colleagues. It's also worth mentioning that a "repeater" has a very
specific meaning in "classical" networking environments, remembering the
old days of FOIRL and the like...that may be another reason to avoid the
use of this notion within the roll context.
	
	* "Actuators may generally be mobile but are likely to be static
in the majority of near-future roll-outs": seems a bit contradictory.
Don't you want to simply say that in a near-future the majority will be
static?
	[CJ] Not quite, because actuators can be devices used by people
who move from one place to another to check how the sensor network is
doing. I think both cases are valid, and would therefore stick to the
current wording. 
	
	* "Similar to the access points, actuator nodes do not suffer
from any long-term resource constraints." what about battery-operated
actuators ?
	[CJ] I'll leave that one to my colleagues :-) 
	
	Section 3.1.4
	###########
	* "pollution data, such as polluting gases (SO2, NOx, CO,
Ozone),
	 heavy metals (e.g.  Mercury), pH, radioactivity, etc;" =>
please expand acronym when first used.
	[CJ] Hmmm...I don't see too many acronyms in that sentence,
actually. This is chemistry stuff, unless you're suggesting we provide
the "lettered" designation of these substances like carbon oxyde, etc.?
I wouldn't go that way... 
	
	* "These meters will be capable of
	   advanced sensing functionalities such as measuring quality of
	   service, providing granular interval data, or automating the
	   detection of alarm conditions."
	You may want to more accurately define the term "quality of
service" since as you know, we used that term of other purposes in IETF
documents.
	[CJ] Agreed. Since this is a list of examples, I would suggest
something like "measuring the quality of the water provided to the
customers".
	
	* In addition they may be capable of
	   advanced interactive functionalities such as remote service
	   disconnect or remote demand reset." => in this case, they are
also acting as actuators.
	[CJ] Agreed. 
	
	Section 3.2 
	#########
	
	[CJ] OK. 
	
	* "The network MUST be capable of supporting the organization of
	   a large number of sensing nodes into regions containing on
the order
	   of 10^2 to 10^4 sensing nodes each."
	JP> Thanks to make this "MUST" routing-specific and move it to
the requirements section.
	[CJ] Agreed - would suggest this should be the introductory
sentence of section 6.1. 
	
	Section 3.3
	#########
	
	* RFID: expand acronym (Radio Frequency IDentification) and add
to the terminology section
	[CJ] OK. 
	
	* s/battery-powered nodes/battery powered nodes
	[CJ] OK. 
	"Sensor nodes are capable of forwarding data." In other words,
they can act as routers. No need to repeat this here.
	[CJ] Fair enough. 
	
	Section 3.4
	#########
	
	* "2.  packet errors due to medium access control;" JP> It is
not really "packet error" here.
	[CJ] Do you mean "transmission erros"? If so, I would agree with
you that this wording is better, but then I guess it should be used for
first three cases, right? 
	
	* Some available protocols may cause packets of neighbouring
nodes to collide and hence cause a link outage." JP> You may want to be
more specific "Some" ?
	[CJ] Do you mean examples, because the previous sentence
mentions the L2 protocols this sentence refers to?
	
	* "if ISM bands are to be used.  For instance, if the 2.4GHz ISM
band is
	   used to facilitate communication between U-LLN nodes, then
heavily
	   loaded WLAN hot-spots become a detrimental performance factor
	   jeopardizing the functioning of the U-LLN."
	JP> Please expand acronym when first used and add to the
terminology section (ISM, WLAN, ...)
	[CJ] OK. 
	
	* Don't you want to say a few words about the varying BER
leading to potentially even higher packet error loss ratio?
	[CJ] Expand the acronym ;-) I agree, bit error rate
considerations should deserve a couple of sentences in this section. 
	
	Section 4.1
	#########
	
	* "Pre-programmed MAC": expand acronym
	[CJ] OK. 
	
	* "the autonomous organization" => self-organizing?
	[CJ] Much better indeed. 
	
	* "For example, nodes in urban sensor nodes SHOULD be able to:"
=> Several of the requirements that follow are nor routing specific. You
may either want to change the SHOULD for a "should" or just focus on the
routing aspects and move them to the routing requirements section.
	[CJ] They may not be routing specific, but I think they do
affect how routing policies are enforced. I woudl therefore suggest we
stick to the proposed wording. 
	
	* "o  Dynamically compute, select and possibly optimize the
(multiple)
	      path(s) that will be used by the participating devices to
forward
	      the traffic towards the actuators and/or the access point
	      according to the service-specific and traffic-specific
QoS,
	      traffic engineering and security policies that will have
to be
	      enforced at the scale of a routing domain (that is, a set
of
	      networking devices administered by a globally unique
entity), or a
	      region of such domain (e.g. a metropolitan area composed
of
	      clusters of sensors)."
	JP> You list important and stringent requirements here. Do you
really need a routing algorithms capable of computing a path on a per
QoS/service specific/... Basis ?
	[CJ] I don't read this sentence as you do. What I meant here is
that entities that operate urban sensor networks specify their own
policies (routing, te, security, QoS, etc.), which may be
service-specific. The requirement suggests that the devices involved in
the enforcement of such policies should behave accordingly, that is,
compute, select, establish and maintain paths whose characteristics
comply with these policies. But I agree this is a strong requirement,
but not stronger than, say, the self-organization requirement.
	
	Section 4.2
	#########
	
	* "After the initialization phase and possibly some operational
time,
	   new nodes may be injected into the network as well as
existing nodes
	   removed from the network.  The former might be because a
removed node
	   is replaced or denser readings/actuations are needed or
routing
	   protocols report connectivity problems. "
	JP> Just to avoid any mis-interpretation when referring to
routing problem, you mean that it may be desirable to inject to node
because connectivity is not sufficient (lack of enough redundant path,
...) and not because of a routing issue per say.
	[CJ] Not necessarily because connectivity is insufficient (new
services, network expansion, node maintenance, etc.), and not
necessarily because there is a routing issue, indeed. 
	
	* "Differentiation
	   SHOULD be made between node disappearance, where the node
disappears
	   without prior notification, and user or node-initiated
disassociation
	   ("phased-out"), where the node has enough time to inform the
network
	   about its removal."
	JP> Again this is not a routing requirement. Unless you refer to
the ability for the routing protocol to advertise to the rest of the
network that it will be removed in order for the other node to
re-compute their path and avoid traffic disruption (e.g. Similarly to
what we do with the ISIS overload bit for example.) Is it what you mean
? 
	[CJ] This is indeed what we meant (at least that's my reading of
this sentence, but I'll let my colleagues further comment on that). If
so, please clarify and move the routing requirement (SHOULD in capital
letter to the routing requirement section).
	[CJ] OK. 
	
	* "The protocol(s) hence SHOULD support the pinpointing of
problematic routing areas"
	JP> Could you clarify what you mean by "pinpointing" since it
could be interpreted in many ways? 
	[CJ] Fair enough, we need to be more explicit. Maybe something
like: "the protocol should be able to convey information about
malfunctioning nodes which may affect or jeopardize the overall routing
efficiency, so that self-configuration capabilities of the sensor
network might be solicited to facilitate the appropriate
reconfiguration."
	
	* The following section also requires some clarification - you
wrote:
	"Furthermore, to inform the
	   access point(s) of the node's arrival and association with
the
	   network as well as freshly associated nodes about packet
forwarding
	   schedules, roles, etc, appropriate (link state) updating
mechanisms
	   SHOULD be supported."
	JP> Are you explicitly requiring a Link State routing protocol
or a routing protocol that provides information about link states or ...
?
	[CJ] We meant "a protocol that can provide information about
link status", indeed. 
	Note that a requirement document should stay solution agnostic
and stay focus on the requirement. 
	[CJ] Fully agreed. 
	Is you requirement that any node needs to have visibility on
other node characteristics with no attempt of aggregation?
	[CJ] Well, yes, presumably depending on design considerations:
cluster head vs. clients within the cluster, for example. I think this
is typical Self Organizing Networking capability.
	
	Section 4.3
	#########
	
	* "The protocol(s) hence MUST support a large number of highly
	   directional unicast flows from the sensing nodes or sensing
clusters
	   towards the access point or highly directed multicast or
anycast
	   flows from the nodes towards multiple access points."
	JP> I think that what you mean is that the routing protocol MUST
be optimized for Multipoint-to-Point traffic patterns (from
sensors/actuators to Sink). As written, it is not clear whether you
refer to it as a routing requirement ?
	[CJ] Agreed. 
	This in fact what you wrote in section 6.5: "To this end, the
routing protocol(s) SHOULD support and utilize the fact of highly
directed traffic flow to facilitate scalability and parameter
constrained routing."
	[CJ] Correct. 
	
	* s/ More generally, entire routing areas may be avoided at e.g.
night but heavily used during the day when nodes are scavenging from
sunlight/ More generally, entire routing areas may be avoided (e.g. at
night) but heavily used during the day when nodes are scavenging from
sunlight.
	JP> Doesn't this translate to the requirement for time-based
routing (some form of policy routing) ?
	[CJ] Correct, but I don't see any harm in providing a practical
example. 
	
	Section 4.4
	#########
	
	"However, they are not very stringent where
	   latencies SHOULD simply be sufficiently smaller than typical
	   reporting intervals"
	JP> This is certainly true but not a routing requirement but a
data plane requirement unless you refer to the ability to support QoS
aware routing where each node may want to be able to compute different
paths depending on the traffic requirements?
	[CJ] This is indeed related to the third bullet that appears in
section 4.1. 
	
	* Move "U-LLN network devices SHOULD support unicast and
multicast routing capabilities" to the routing requirement section. You
may want to leave the sentence here (without a SHOULD).
	[CJ] OK. 
	
	* You use the term "anycast" that has been discussed in the
past, in particular in the context of the Home routing requirement
document. I would suggest to define this term in the document, refer to
RFC4291 or RFC1546, ...
	[CJ] Fully agreed. 
	
	Section 4.5
	#########
	
	* "An alarm is likely being
	   registered by a plurality of sensing nodes where the delivery
of a
	   single alert message with its location of origin suffices in
most
	   cases."
	Then you provide the example of toxic gas level. This is one
example where it might be desirable not to perform data
aggregation/fusion and get multiple copies of the same message from
different source to perform "triangulation" and better localize the
incident.
	[CJ] Agreed, but I think this example precisely illustrates the
issue. 
	
	* "Routing within urban sensor networks SHOULD require the U-LLN
nodes
	   to dynamically compute, select and install different paths
towards a
	   same destination, depending on the nature of the traffic.
>From this
	   perspective, such nodes SHOULD inspect the contents of
traffic
	   payload for making routing and forwarding decisions: 
	
	JP> This clarifies my previous question; you do refer to ability
to compute different paths (with different characteristic). Note that
the path selection process performed by the sender and potentially
routers along the path is not strictly speaking a routing requirement.
	Move this requirement to the requirement section. 
	[CJ] OK. 
	
	* "for example, the analysis of the traffic payload SHOULD be
derived into aggregation
	   capabilities for the sake of forwarding efficiency."
	JP> Can you clarify what you mean here?
	[CJ] The analysis of the payload of several packets should help
in making forwarding decisions that will spare network resources.
	
	* "Delays and latencies are
	   important; however, again, deliveries within seconds SHOULD
suffice
	   in most of the cases."
	JP> Clearly not a routing requirement!
	[CJ] Agreed. 
	
	Section 5
	########
	
	* "The network SHOULD take into consideration that different
application
	   traffic may require different priorities when traversing the
network,
	   and that some traffic may be more sensitive to latency."
	JP> If by priorities you mean different routes with different
characteristics then this is fine and already covered. If you refer to
packet marking to provide different QoS in the data plane, this is not a
routing requirement.
	[CJ] Agreed - the former is the correct interpretation. 
	
	* "An U-LLN SHOULD support occasional large scale traffic flows
from
	   sensing nodes to access points, such as system-wide alerts. "
and "A node MUST be able to send its own alerts toward an access
	   point while continuing to forward traffic on behalf of other
devices
	   who are also experiencing an alert condition.  The network
MUST be
	   able to manage this sudden large traffic flow."
	JP> Not routing requirements. Unless ... You require the ability
to compute multiple paths and use all of them (symmetrical or
asymmetrical routing ???) to spread out the traffic and limit network
delays ?
	[CJ] I think this is a kind of causality effect: the routing
protocol must be able to accommodate traffic bursts by dynamically
computing and selecting multiple paths towards the same destination. 
	
	* You make an interesting reference to Smart Grid and DR/DSM.
That said, you wrote "The network SHOULD support internetworking, while
giving attention to security implications of interfacing, for example, a
home network with a utility U-LLN."
	JP> Don't you mean that the routing protocol must be able to
potentially interact via potential route redistribution with other
routing protocol used in the Internet, should these two protocols not be
identical ?
	[CJ] Correct. 

	Section 6
	#########
	
	* S/Current urban roll-outs are composed of sometimes more than
a hundred nodes/ Current urban roll-outs are composed of sometimes more
than one hundred nodes
	[CJ] OK. 
	
	* " The routing protocols(s) SHOULD support the organization of
a large number of nodes into regions of to-be-specified size."
	JP> It will be difficult (or too easy ;-)) to be compliant with
that SHOULD with a to-be-specified size. Or did you mean "configurable"
?
	[CJ] Configurable is indeed much better. 
	
	* "To this end, the routing protocol(s) MUST support parameter
	   constrained routing, where examples of such parameters (CPU,
memory
	   size, battery level, etc.) have been given in the previous
paragraph."
	JP> Please use the term "node constrained based routing"
	[CJ] I'm not sure I agree here, because "node-constrained"
sounds more fuzzy to me. "environment-constrained"? 
	
	* "For the latter, the protocol(s) MUST support multi- and
	   any-cast addressing.  The protocol(s) SHOULD also support the
	   formation and identification of groups of field devices in
the
	   network."
	JP> You may want to more accurately define the term "anycast" 
	[CJ] Would the couple of references you righfully mentioned
earlier be sufficient?
	
	* " To mandate fully interoperable implementations, the routing
	   protocol(s) proposed in U-LLN MUST support different devices
and
	   underlying technologies without compromising the operability
and
	   energy efficiency of the network."
	JP> This requires clarification here. Do you mean that the
routing protocol MUST support node constrained based routing? If so, it
is already stated above. The support of different L1/L2 is a given
(route over).
	[CJ] I would agree with Jean-Philippe, and suggest we remove
this wording...but I'll let the co-authors further comment. 
	
	* Section 6.8, as written, is not related to routing but data
plane. Let me be more specific:
	
	* "To this end, the routing protocol(s) SHOULD support minimum
latency
	   for alert reporting and time-critical data queries."
	JP> The support of minimum latency path (data plane !) or the
support for different metric path (control plane) ?
	[CJ] As written, I read it as the former interpretation and
would suggest we remove the text. 
	
	* "For regular data
	   reporting, it SHOULD support latencies not exceeding a
fraction of
	   the smallest reporting interval.  "
	JP> Not a routing requirement. Even if you are referring to a
bound on the total path metric (the metric reflecting the delay in this
case), this is an implementation issue.
	[CJ] Correct. 
	
	* "Due to the different latency requirements, the routing
protocol(s) SHOULD support the ability of dealing with different latency
requirements.  The routing protocol(s) SHOULD also support the ability
to route according to different metrics (one of which could e.g. be
latency)."
	JP> yes these are routing requirements although I would suggest
to remove the first sentence, the requirement being captured in the
second sentence.
	[CJ] Agreed. 
	
	Section 7
	#########
	
	* "As every network, U-LLNs are exposed to security threats that
MUST be addressed."
	JP> You cannot put a MUST here unless you list the routing
security threats.
	[CJ] OK. 
	
	* s/ potential security threats/ potential routing security
threats => JP> Please use the term "routing security" in place of
"security" throughout the section. 
	[CJ] OK. 
	
	* "U-LLN networks SHOULD support mechanisms to preserve the
	   confidentiality of the traffic that they forward.  The U-LLN
network
	   SHOULD NOT prevent an application from employing additional
	   confidentiality mechanisms."
	JP> I do agree with the requirement but this is not a routing
requirement. 
	[CJ] Fair enough. 
	Could you focus on the routing security issues ? Or are you
referring to the routing traffic confidentiality ?
	[CJ] No, this wording referred to the traffic forwarded by the
network.  
	This is what you do right after:
	[CJ] Correct. 
	" The U-LLN MUST be protected against attempts to inject false
or
	   modified packets.  For example, an attacker SHOULD be
prevented from
	   manipulating or disabling the routing function by
compromising
	   routing update messages.  Moreover, it SHOULD NOT be possible
to
	   coerce the network into routing packets which have been
modified in
	   transit.  To this end the routing protocol(s) MUST support
message
	   integrity."
	JP> I do not see any reference to the type of routing attacks
that could be performed on such networks because of the typical P2MP
traffic pattern, extensive use of wireless links, ... 
	[CJ] OK, but does that mean we should not consider such
requirement? I don't think so, afaic. 
	JP> What I would suggest is to re-focus on the routing security
issues with the Security expert that will get appointed.
	[CJ] OK. 
	
	Reference section
	###############

	   [I-D.brandt-roll-home-routing-reqs]
	              Brandt, A., "Home Automation Routing Requirement
in Low
	              Power and Lossy Networks",
	              draft-brandt-roll-home-routing-reqs-01 (work in
progress),
	              May 2008.
	
	JP> Please update to draft-ietf-roll-home-routing-reqs and add
the reference to draft-ietf-roll-indus-routing-reqs
	[CJ] OK. 
	
	   [I-D.culler-rl2n-routing-reqs]
	              Vasseur, J. and D. Cullerot, "Routing Requirements
for Low
	              Power And Lossy Networks",
	              draft-culler-rl2n-routing-reqs-01 (work in
progress),
	              July 2007.
	
	[CJ] OK. 

	Last comment: please check that you expand acronyms when first
used.
	[CJ] OK.
	 
	Cheers,
	 
	Christian. 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Mischa Dohler" <[email-masked]>
Date: Fri, 22 Aug 2008 11:20:41 +0200

Thanks, JP, indeed, for this in-depth review. I propose that Tim takes care
of all the small typos identified by JP. Some comments in-line in addition
to Christian ones. Thanks to all and kind regards, Mischa.

  _____  

From: [email-masked]
[mailto:[email-masked]] 
Sent: Thursday, August 21, 2008 11:02 PM
To: JP Vasseur; Mischa Dohler; Tim Winter; WATTEYNE Thomas RD-TECH;
MADHUSUDAN Giyyarpuram RD-TECH; CHEGARAY Gabriel RD-TECH; BARTHEL Dominique
RD-TECH; [email-masked]
Cc: David E. Culler
Subject: RE: Review of draft-ietf-roll-urban-routing-reqs-01

Dear all,

Thanks to Jean-Philippe for this thorough review. Please find a first shot
of personal comments inline, but I'll let my fellow co-authors further
elaborate accordingly.

[CJ] [snip] 
Abstract
#######

JP> You may want to use a different word than "Autonomous". Do you refer to
the "self configuration" property ?
[CJ] We chose "autonomous" because it was generic enough, while I think
"self configuration" is too restrictive: it's not only a matter of
configuration, it's also a matter of making (forwarding) decisions,
self-healing capabilities, etc. Another word I would suggest is
"self-organizing", if this is more specific. 
[Mischa] We had long discussions on this and finally converged to <
autonomous >. Let's leave it. 

Section 1
#######
* "Section 6 discusses the routing requirements for networks comprising

JP> Please remove this reference (ID abandoned) and insert reference to
<http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.tx
t>
http://www.ietf.org/internet-drafts/draft-ietf-roll-home-routing-reqs-02.txt
,
<http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.t
xt>
http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.tx
t and
<http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-
reqs-00.txt>
http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-r
eqs-00.txt.
[CJ] OK. 

Section 2
########

* Schedule:  An agreed execution, wake-up, transmission, reception,
         etc., time-table between two or more field devices.
The definition is a little bit too vague. If used in the generic sense, no
need to add it to the terminology section. Otherwise, it ought to be more
specific.
[CJ] Schedule is indeed very generic, but I think the sue of the word makes
perfect sense in the context of U-WSN networks. Being more specific would
mean elaborating on use cases where schedule information is taken into
account by field devices to perform some specific action. If this proposal
makes sense, I'm not sure the terminology section is appropriate for such
elaboration and would therefore suggest we (1) keep the "schedule"
definition in this section and (2) further elaborate on a use case that
illustrates the use of schedule information in section 5 of the draft. 

[Mischa] I don't see why this is vague. This is very clear to me. Let's
leave it as is (I guess we do not need to find the maximum entropy of this
document; the routing solution won't get better due to this :-)).

Section 3.1.1
###########

* What you refer to as a repeater is in fact a router. What I would suggest
here is to reword this paragraph to indicate that some nodes are simple
routers whereas other nodes are routers and lso perform sensing/actuating
task. Insert this paragraph after the Actuators and Sensors paragraphs.
[CJ] So you're suggesting to (1) remove section 3.1.2 (not 3.1.1, actually),
and (2) indicate that some nodes are routers (not "simple", btw :-), others
also perform sensing/actuating tasks, right? I'm fine with this suggestion,
but I'd like to hear the feedback from my colleagues. It's also worth
mentioning that a "repeater" has a very specific meaning in "classical"
networking environments, remembering the old days of FOIRL and the
like...that may be another reason to avoid the use of this notion within the
roll context.
[Mischa] We had this discussion before and the reason outlined by Christian
is exactly why the thingy is called repeater and not router. 

* "Actuators may generally be mobile but are likely to be static in the
majority of near-future roll-outs": seems a bit contradictory. Don't you
want to simply say that in a near-future the majority will be static?
[CJ] Not quite, because actuators can be devices used by people who move
from one place to another to check how the sensor network is doing. I think
both cases are valid, and would therefore stick to the current wording. 

[Mischa] When I wrote this I had more in mind what JP said in shortened
form. I personally hence propose to change as suggested by JP.

* "Similar to the access points, actuator nodes do not suffer from any
long-term resource constraints." what about battery-operated actuators ?
[CJ] I'll leave that one to my colleagues :-) 
[Mischa] This is a difficult one. It clearly depends on the application,
which even in the urban context can be infinite. There will be applications
where acting nodes just switch something or reset something and hence need
minimal energy allowing them to operate on batteries and hence be < resource
constrained >. Other applications will require actuators which need to do
heavy stuff with loads of energy, one hence needs the mains. I propose to
change it to reflect the two cases < Actuator node may also suffer from any
. >  

Section 3.1.4
###########
* "pollution data, such as polluting gases (SO2, NOx, CO, Ozone),
 heavy metals (e.g.  Mercury), pH, radioactivity, etc;" => please expand
acronym when first used.
[CJ] Hmmm...I don't see too many acronyms in that sentence, actually. This
is chemistry stuff, unless you're suggesting we provide the "lettered"
designation of these substances like carbon oxyde, etc.? I wouldn't go that
way... 

[Mischa] :-) I agree with Christian. Let's leave that basic stuff which I
think is part of SI and hence does not need to spelled out.

* "These meters will be capable of
   advanced sensing functionalities such as measuring quality of
   service, providing granular interval data, or automating the
   detection of alarm conditions."
You may want to more accurately define the term "quality of service" since
as you know, we used that term of other purposes in IETF documents.
[CJ] Agreed. Since this is a list of examples, I would suggest something
like "measuring the quality of the water provided to the customers".
[Mischa] I agree with both.

* In addition they may be capable of
   advanced interactive functionalities such as remote service
   disconnect or remote demand reset." => in this case, they are also acting
as actuators.
[CJ] Agreed. 
[Mischa] I agree.

Section 3.2 
#########

* "The network MUST be capable of supporting the organization of
   a large number of sensing nodes into regions containing on the order
   of 10^2 to 10^4 sensing nodes each."
JP> Thanks to make this "MUST" routing-specific and move it to the
requirements section.
[CJ] Agreed - would suggest this should be the introductory sentence of
section 6.1. 
[Mischa] I agree with both.

Section 3.3
#########

* s/battery-powered nodes/battery powered nodes
[CJ] OK. 
"Sensor nodes are capable of forwarding data." In other words, they can act
as routers. No need to repeat this here.
[CJ] Fair enough. 

Section 3.4
#########

* "2.  packet errors due to medium access control;" JP> It is not really
"packet error" here.
[CJ] Do you mean "transmission erros"? If so, I would agree with you that
this wording is better, but then I guess it should be used for first three
cases, right? 
[Mischa] Collision resulting from poor MAC yield packet errors. We had
discussed this section numerous times. I propose to leave it as is.

* Some available protocols may cause packets of neighbouring nodes to
collide and hence cause a link outage." JP> You may want to be more specific
"Some" ?
[CJ] Do you mean examples, because the previous sentence mentions the L2
protocols this sentence refers to?
[Mischa] Yes, this is a L 2 issue and I am a little confused here : at one
iterative point you insist to minimize if not delete all references to L2
and here you ask to be more specific. I give you an example for you to
understand but propose this not to be included : reservation based MACs can
guarantee a collision-free schedule whereas contention-based MACs, MACs with
common schedules and preamble-based MACs cannot. Therefore < some >. 

* "if ISM bands are to be used.  For instance, if the 2.4GHz ISM band is

* Don't you want to say a few words about the varying BER leading to
potentially even higher packet error loss ratio?
[CJ] Expand the acronym ;-) I agree, bit error rate considerations should
deserve a couple of sentences in this section. 
[Mischa] We purposedly don't talk about BER but about PER - they are VERY
different, mainly because you can use different channel codes. For instance,
a BCH code which is capable of correcting 5 errors does not care much about
small BER variations. Large changes, however, will effect the performance
but we are effecitvely interested in PER. I personally think that all needed
information is in there. 

Section 4.1
#########

* "For example, nodes in urban sensor nodes SHOULD be able to:" => Several
of the requirements that follow are nor routing specific. You may either
want to change the SHOULD for a "should" or just focus on the routing
aspects and move them to the routing requirements section.
[CJ] They may not be routing specific, but I think they do affect how
routing policies are enforced. I woudl therefore suggest we stick to the
proposed wording. 
[Mischa] I tend to agree with Christian.

* "o  Dynamically compute, select and possibly optimize the (multiple)
      path(s) that will be used by the participating devices to forward
      the traffic towards the actuators and/or the access point
      according to the service-specific and traffic-specific QoS,
      traffic engineering and security policies that will have to be
      enforced at the scale of a routing domain (that is, a set of
      networking devices administered by a globally unique entity), or a
      region of such domain (e.g. a metropolitan area composed of
      clusters of sensors)."
JP> You list important and stringent requirements here. Do you really need a
routing algorithms capable of computing a path on a per QoS/service
specific/... Basis ?
[CJ] I don't read this sentence as you do. What I meant here is that
entities that operate urban sensor networks specify their own policies
(routing, te, security, QoS, etc.), which may be service-specific. The
requirement suggests that the devices involved in the enforcement of such
policies should behave accordingly, that is, compute, select, establish and
maintain paths whose characteristics comply with these policies. But I agree
this is a strong requirement, but not stronger than, say, the
self-organization requirement.
[Mischa] We only need to make sure that this is not a MUST requirement
because there are solutions out there which don't need all these
computations.

Section 4.2
#########

* "After the initialization phase and possibly some operational time,
   new nodes may be injected into the network as well as existing nodes
   removed from the network.  The former might be because a removed node
   is replaced or denser readings/actuations are needed or routing
   protocols report connectivity problems. "
JP> Just to avoid any mis-interpretation when referring to routing problem,
you mean that it may be desirable to inject to node because connectivity is
not sufficient (lack of enough redundant path, ...) and not because of a
routing issue per say.
[CJ] Not necessarily because connectivity is insufficient (new services,
network expansion, node maintenance, etc.), and not necessarily because
there is a routing issue, indeed. 

* "Differentiation
   SHOULD be made between node disappearance, where the node disappears
   without prior notification, and user or node-initiated disassociation
   ("phased-out"), where the node has enough time to inform the network
   about its removal."
JP> Again this is not a routing requirement. Unless you refer to the ability
for the routing protocol to advertise to the rest of the network that it
will be removed in order for the other node to re-compute their path and
avoid traffic disruption (e.g. Similarly to what we do with the ISIS
overload bit for example.) Is it what you mean ? 
[CJ] This is indeed what we meant (at least that's my reading of this
sentence, but I'll let my colleagues further comment on that). 

[Mischa] Yes, this is what we mean.

If so, please clarify and move the routing requirement (SHOULD in capital
letter to the routing requirement section).
[CJ] OK. 

* "The protocol(s) hence SHOULD support the pinpointing of problematic
routing areas"
JP> Could you clarify what you mean by "pinpointing" since it could be
interpreted in many ways? 
[CJ] Fair enough, we need to be more explicit. Maybe something like: "the
protocol should be able to convey information about malfunctioning nodes
which may affect or jeopardize the overall routing efficiency, so that
self-configuration capabilities of the sensor network might be solicited to
facilitate the appropriate reconfiguration."

[Mischa] And I would add < This information may e.g. be in the form of exact
or relative geographical position, etc. >

* The following section also requires some clarification - you wrote:
"Furthermore, to inform the
   access point(s) of the node's arrival and association with the
   network as well as freshly associated nodes about packet forwarding
   schedules, roles, etc, appropriate (link state) updating mechanisms
   SHOULD be supported."
JP> Are you explicitly requiring a Link State routing protocol or a routing
protocol that provides information about link states or ... ?
[CJ] We meant "a protocol that can provide information about link status",
indeed. 
[Mischa] I remind you however that this is SHOULD and not MUST.

Note that a requirement document should stay solution agnostic and stay
focus on the requirement. 
[CJ] Fully agreed. 

Is you requirement that any node needs to have visibility on other node
characteristics with no attempt of aggregation?
[CJ] Well, yes, presumably depending on design considerations: cluster head
vs. clients within the cluster, for example. I think this is typical Self
Organizing Networking capability.

Section 4.3
#########

[Mischa] No, our requirement is stronger. Multipoint can be from many < some
where > nodes to one sink. What we mean is many < geographically close >
nodes to one sink. This is an underlying property of WSNs and our routing
solutions HEAVILY rely on this.

This in fact what you wrote in section 6.5: "To this end, the routing
protocol(s) SHOULD support and utilize the fact of highly directed traffic
flow to facilitate scalability and parameter constrained routing."
[CJ] Correct. 

* s/ More generally, entire routing areas may be avoided at e.g. night but
heavily used during the day when nodes are scavenging from sunlight/ More
generally, entire routing areas may be avoided (e.g. at night) but heavily
used during the day when nodes are scavenging from sunlight.
JP> Doesn't this translate to the requirement for time-based routing (some
form of policy routing) ?
[CJ] Correct, but I don't see any harm in providing a practical example. 
[Mischa] I agree with Christian.

Section 4.4
#########

[CJ] This is indeed related to the third bullet that appears in section 4.1.

* Move "U-LLN network devices SHOULD support unicast and multicast routing
capabilities" to the routing requirement section. You may want to leave the
sentence here (without a SHOULD).
[CJ] OK. 

* You use the term "anycast" that has been discussed in the past, in
particular in the context of the Home routing requirement document. I would
suggest to define this term in the document, refer to RFC4291 or RFC1546,
...
[CJ] Fully agreed. 

Section 4.5
#########

* "An alarm is likely being
   registered by a plurality of sensing nodes where the delivery of a
   single alert message with its location of origin suffices in most
   cases."
Then you provide the example of toxic gas level. This is one example where
it might be desirable not to perform data aggregation/fusion and get
multiple copies of the same message from different source to perform
"triangulation" and better localize the incident.
[CJ] Agreed, but I think this example precisely illustrates the issue. 

* "Routing within urban sensor networks SHOULD require the U-LLN nodes

* "for example, the analysis of the traffic payload SHOULD be derived into
aggregation
   capabilities for the sake of forwarding efficiency."
JP> Can you clarify what you mean here?
[CJ] The analysis of the payload of several packets should help in making
forwarding decisions that will spare network resources.

Section 5
########

* "The network SHOULD take into consideration that different application

* "An U-LLN SHOULD support occasional large scale traffic flows from
   sensing nodes to access points, such as system-wide alerts. " and "A node
MUST be able to send its own alerts toward an access
   point while continuing to forward traffic on behalf of other devices
   who are also experiencing an alert condition.  The network MUST be
   able to manage this sudden large traffic flow."
JP> Not routing requirements. Unless ... You require the ability to compute
multiple paths and use all of them (symmetrical or asymmetrical routing ???)
to spread out the traffic and limit network delays ?
[CJ] I think this is a kind of causality effect: the routing protocol must
be able to accommodate traffic bursts by dynamically computing and selecting
multiple paths towards the same destination. 
[Mischa] Agreed.

* You make an interesting reference to Smart Grid and DR/DSM. That said, you
wrote "The network SHOULD support internetworking, while giving attention to
security implications of interfacing, for example, a home network with a
utility U-LLN."
JP> Don't you mean that the routing protocol must be able to potentially
interact via potential route redistribution with other routing protocol used
in the Internet, should these two protocols not be identical ?
[CJ] Correct. 

Section 6
#########

* " The routing protocols(s) SHOULD support the organization of a large
number of nodes into regions of to-be-specified size."
JP> It will be difficult (or too easy ;-)) to be compliant with that SHOULD
with a to-be-specified size. Or did you mean "configurable" ?
[CJ] Configurable is indeed much better. 

* "To this end, the routing protocol(s) MUST support parameter
   constrained routing, where examples of such parameters (CPU, memory
   size, battery level, etc.) have been given in the previous paragraph."
JP> Please use the term "node constrained based routing"
[CJ] I'm not sure I agree here, because "node-constrained" sounds more fuzzy
to me. "environment-constrained"? 
[Mischa] Parameter constrained is the right word. For instance node internal
parameters (CPU, etc) and also environment parameters (avilability of sun
and therefore availability of energy due to energy scavanging, etc)

[CJ] Would the couple of references you righfully mentioned earlier be
sufficient?

* " To mandate fully interoperable implementations, the routing
   protocol(s) proposed in U-LLN MUST support different devices and
   underlying technologies without compromising the operability and
   energy efficiency of the network."
JP> This requires clarification here. Do you mean that the routing protocol
MUST support node constrained based routing? If so, it is already stated
above. The support of different L1/L2 is a given (route over).
[CJ] I would agree with Jean-Philippe, and suggest we remove this
wording...but I'll let the co-authors further comment. 
[Mischa] Imagine a network composed of simple ZigBee nodes and a few WLAN
nodes which have a ZigBee interface. An optimum solution will use the WLAN
nodes as a virtual information backbone and connect the ZigBee nodes to the
WLAN nodes. You can turn this as you want but an optimal routing solution
would never treat nodes of different capabilities the same (eg build a flat
routing structure). Therefore, any routing algorithm should ideally make use
of this heterogeneity. I would be happy to change this MUST for SHOULD
(which is what I had proposed, I think, a few weeks ago).

* "To this end, the routing protocol(s) SHOULD support minimum latency
   for alert reporting and time-critical data queries."
JP> The support of minimum latency path (data plane !) or the support for
different metric path (control plane) ?
[CJ] As written, I read it as the former interpretation and would suggest we
remove the text. 

* "For regular data

* "Due to the different latency requirements, the routing protocol(s) SHOULD
support the ability of dealing with different latency requirements.  The
routing protocol(s) SHOULD also support the ability to route according to
different metrics (one of which could e.g. be latency)."
JP> yes these are routing requirements although I would suggest to remove
the first sentence, the requirement being captured in the second sentence.
[CJ] Agreed. 

Section 7
#########

* "As every network, U-LLNs are exposed to security threats that MUST be
addressed."
JP> You cannot put a MUST here unless you list the routing security threats.
[CJ] OK. 

* s/ potential security threats/ potential routing security threats => JP>
Please use the term "routing security" in place of "security" throughout the
section. 
[CJ] OK. 

Could you focus on the routing security issues ? Or are you referring to the
routing traffic confidentiality ?
[CJ] No, this wording referred to the traffic forwarded by the network.  
This is what you do right after:
[CJ] Correct. 
" The U-LLN MUST be protected against attempts to inject false or
   modified packets.  For example, an attacker SHOULD be prevented from
   manipulating or disabling the routing function by compromising
   routing update messages.  Moreover, it SHOULD NOT be possible to
   coerce the network into routing packets which have been modified in
   transit.  To this end the routing protocol(s) MUST support message
   integrity."
JP> I do not see any reference to the type of routing attacks that could be
performed on such networks because of the typical P2MP traffic pattern,
extensive use of wireless links, ... 
[CJ] OK, but does that mean we should not consider such requirement? I don't
think so, afaic. 
JP> What I would suggest is to re-focus on the routing security issues with
the Security expert that will get appointed.
[CJ] OK. 

Reference section
###############

Cheers,

Christian. 

*********************************
This message and any attachments (the "message") are confidential and
intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed
or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
********************************