Subject: [Roll] home-routing-reqs-02 comments

From: Zach Shelby <[email-masked]>
Date: Thu, 24 Jul 2008 15:44:03 +0300

Anders, Giorgio,

Here are a few comments. In general the draft is really good.

Section 3.9 doesn't seem to fit into Chapter 3 (Applications). It would 
be better in Chapter 4 tied to a requirement on battery-powered.

The list of applications in Chapter 3 is useful, but it is hard to pick 
out and compare the requirements they have. Could a short table be added 
to summarize their requirements and differences?

I'm concerned about Section 4.1 (similar requirement is found from the 
commercial building draft as well). How can we ensure that in ROLL? 
Grouping like this, which can't be achieved by existing IPv6 mechanisms 
should be dealt with at the application layer. So does this belong in 
this draft as a requirement? Maybe a looser requirement on what the 
routing algorithm should do to support applications using groups is 
appropriate?

The last paragraph on Section 4.3 comes to the conclusion that mobility 
is the main reason for non-responsive nodes. How about sleeping nodes, 
which is likely the main cause. You probably assumed that and just 
didn't mention it. Maybe we could be explicit about sleeping nodes here. 
E.g. non-reachability because battery-powered nodes are sleeping is 
common, but we assume that nodes are aware of sleeping schedules somehow.

Section 4.4 is a bit dangerous when it comes to periodic scanning. 
Reading levis-protocols-survey there is a good discussion on period 
control traffic without data traffic. Should periodic scanning really be 
a MUST here? Isn't it enough that neighbors are recognized (e.g. using 
L2 triggers) without the use of periodic scanning which in the absence 
of any data is not ideal.

In Section 4.6 the convergence time could be defined better? Is that the 
RREQ time e.g. in a distance-vector algorithm? Src -> RREQ -> Dst -> 
RREP -> Src. Or is it the RREQ time plus the first RTT after that?

In Section 7 I think the current security discussion there is irrelevant 
to roll. But I think the open issue on security is meant to add routing 
related security issues, which do belong there.

-- 
Zach Shelby | Head of Research | +358 40 7796297
Sensinode Ltd.   www.sensinode.com
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll