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

[JP Vasseur <[e-mail]>]

Hi,

Thanks for the quick replies  !  See in line


On 8/22/08 11:20 AM, "Mischa Dohler" <[e-mail]> wrote:

> 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: [e-mail]
> [mailto:[e-mail]]
> 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;
> [e-mail]
> 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
>> #######
>> 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.
>> [Mischa] We had long discussions on this and finally converged to «
>> autonomous ». Let¹s leave it.
>> 
>> JP> This is fine, just add a definition of ³Autonomous² then.
>> 
>> 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-02.txt
>> > , 
>> http://www.ietf.org/internet-drafts/draft-ietf-roll-indus-routing-reqs-01.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-re
>> qs-00.txt 
>> <http://www.ietf.org/internet-drafts/draft-martocci-roll-commercial-routing-r
>> eqs-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.
>> [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 J).
>> JP> I must say that I like the proposal of Christian to further elaborate
>> (one or two example are sufficient) on a use case. I can see at least 3-4
>> ways the word ³Schedule² may be interpreted.
>> 
>> Section 3.1.1
>> ###########
>> * S/ pre- planned location/ pre-planned location
>> [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.
>> [Mischa] We had this discussion before and the reason outlined by Christian
>> is exactly why the thingy is called repeater and not router.
>> JP> As pointed out, the word ³repeaters² has been used for other purposes ...
>> What you refer to as a ³repeater² is an ³router². I would suggest not to
>> adopt a specific terminology for this ID.
>>  
>> * ³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.
>> 
>> JP>OK
>> 
>> * ³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 Š
>> »  
>> 
>> JP> Agree.
>> 
>> 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] J 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 
>> #########
>> 
>> * s/ between one other/between each other
>> [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. 
>> [Mischa] I agree with both.
>> 
>> 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? 
>> [Mischa] Collision resulting from poor MAC yield packet errors. We had
>> discussed this section numerous times. I propose to leave it as is.
>> JP> Just list a few potential error types.
>> 
>> * 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 ».
>> JP> After reread the sentence, I agree, the sentence is fine as is.
>> 
>> * ³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.
>> [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.
>> JP> Just add what you mentioned, and we¹re fine.
>> 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. 
>> [Mischa] I tend to agree with Christian.
>> JP> Looking at the text here:
>> 
>> For example, nodes in urban sensor nodes SHOULD be able to:
>> 
>>    o  Dynamically adapt to ever-changing conditions of communication
>>       (possible degradation of QoS, variable nature of the traffic (real
>>       time vs. non real time, sensed data vs. alerts, node mobility, a
>>       combination thereof, etc.),
>> 
>> JP> As an routing solution implementer, how should I interpret the normative
>> SHOULD here, first bullet ? Here is what I propose:
>> * You may either reword the paragraph with a routing specific approach. I see
>> what you mean here but you may need to explain what it means for the routing
>> protocol to adapt to changing condition of communication. Note that the
>> SHOULD relies to routing engines, not the node itself.
>> * Change the SHOULD for a non normative should.
>> 
>> 
>>    o  Dynamically provision the service-specific (if not traffic-
>>       specific) resources that will comply with the QoS and security
>>       requirements of the service,
>> 
>> JP> When you write ³ The node SHOULD dynamically provision the
>> service-specific resources ...² then it is not a routing requirement.
>> 
>> * ³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.
>> JP> That clarifies, thanks.
>> [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.
>> JP> OK.
>> 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.
>> JP> Could you then slightly reword the sentence to clarify ? Thanks.
>> * ³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.
>> JP> OK good. Could you then slightly reword the sentence to clarify ? Thanks.
>> 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. »
>> JP> Agree with the proposed changes.
>> 
>> * 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.
>> JP> OK fair enough, but again a rather solution oriented requirement.
>> 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. 
>> [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.
>> JP> Which ³routing solutions² ;-) ? This is a requirement ID. Then thanks to
>> clarify a bit more this 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.²
>> [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.
>> JP> I just proposing to generalize this example and make it a requirement, if
>> needed.
>> 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.
>> JP> OK then just clarify to avoid mis-interpretation with a dataplane
>> requirement.
>> * 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.
>> JP> But then this is clearly not a requirement unless you refer to path
>> selection.
>> * ³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.
>> JP> OK then just clarify.
>> * ³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.
>> JP> Great, then remove the SHOULD, MUST on the previous paragraph and add a
>> routing requirements related to it with the appropriate SHOULD and MUST.
>> 
>> * 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. 
>> JP> OK, just clarify.
>> 
>> 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"?
>> [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)
>> JP> Fine, leave it unchanged. I need to work on the terminology ID, we¹ll
>> clarify then.
>> 
>> * ³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?
>> JP> Yes thanks.
>> * ³ 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).
>> JP> If you refer to the ability to mix IP with non IP node, then I do
>> disagree. This is not a requirement that we can meet (IETF works on IP). Thus
>> my suggestion to remove this sentence.
>> * 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.
>> JP> OK
>> * ³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.
>> JP> Then it does not really belong to this routing requirement ID.
>> 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> I did not mean to remove these requirements, there are quite needed but
>> to also look at other requirements related to specific routing security
>> attacked of WSN.
>> 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
>> ###############
>> 
>> 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
>> [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.
>> 
>> JP> This one can be removed.
>> [CJ] OK. 
>> 
>> 
>> Last comment: please check that you expand acronyms when first used.
>> [CJ] OK.
>>  
>> JP> Thanks.
>> 
>> Cheers,
>> 
>> JP.
>> 
>> 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.
> ********************************
> 

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll