Subject: [Roll] Industrial Requirements Feedback

From: Jonathan Hui <[email-masked]>
Date: Tue, 11 Mar 2008 22:42:43 -0700

Overall, this is a great start. As a high-level structure, I would
prefer to see up front a complete description of the use-cases and
operation scenario. This would allow the requirements section to
provide a list of concise statements about the requirements. It makes
it much easier for a protocol designer/implementor to verify which
requirements are being addressed.

There are various L2 specific things sprinkled throughout the
draft. ROLL is L2 agnostic, so we should limit these things. For
example, there's specific mention of 802.15.4's bit-rates and even a
requirement for multiple access points and load distribution when
throughput exceeds 100 kbps. Do we still want to require this even
when a different L2 technology can provide 100 kbps with ease? Also,
there's various requirements that seem specific to a slotted L2. Any
assumptions about the link should be generally applicable to any L2.

The draft also mentions various QoS requirements, though I think some
of them aren't really applicable to routing but rather
forwarding. These should be decoupled and we should keep our focus on
routing.

Specific comments:

Section 2: A good section overall, captures a good chunk of the
application scenario. I'd still prefer to see some more about the
expected node capabilities, how they're physically laid out, what the
failure model is, what the mobility scenarios are, etc.

Section 2.1: Good section in defining the different traffic
classes. But it would be good to explicitly state where the traffic is
going and whether this ever changes under different scenarios. At the
end, there's a routing requirement statement. I think such statements
should be left for the requirements section. My comment w.r.t. this
specific requirement is that I don't think it's really in the scope of
a requirements document. It's describing how to meet the routing
requirements in this draft.

Section 3: The QoS section here seems to be addressing more than
routing, but the forwarding architecture as well. For example, I see
bandwidth and latency as directly applicable to routing, but
transmission phase and priority seem more applicable to
forwarding. Note that QoS, in many cases, is provided completely by
forwarding mechanisms. I think it's good to separate these issues
since we're primarily focused on routing. Also, there is mention about
L2 specifics here, however the ROLL WG is L2 agnostic. Any assumptions
about the link should be generally applicable to other links as well.

Section 3.1: Again, mentions specifics about the L2 protocol. Maybe we
can just drop "slotted-link".

Section 4: I think the network topology assumptions should be ahead of
the routing requirements. The requirement for multiple access points
should be in the requirements section. Requirements that assume
specific L2 properties should be left out. ROLL is L2 agnostic and
requiring particular features when throughput exceeds a 100 kbps isn't
appropriate, especially if other L2 technologies may support >100 kbps
with ease.

Section 6: IPv6 does not support a notion of broadcast, only
multicast. Also, the Internet architecture has generally decoupled
unicast routing from multicast routing. So I think we can't require a
single routing protocol to provide both unicast and multicast, but we
not disallow it if one protocol can satisfy both.

Section 7: Would it be more appropriate to state what the actual route
establishment/convergence time requirements are? The re-optimization
rules in this draft don't give a clear indication of the actual
application requirement.

Section 8: I like how the application scenario and requirements here
are very concrete. This is, in general, the kind of requirements I
like to see in these kinds of drafts. Minor nit with "reconfiguring
graphs" as such reconfiguration may not actually require the routing
topology to change.

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

---

From: "Eunsook \"Eunah\" Kim" <[email-masked]>
Date: Wed, 12 Mar 2008 18:11:02 -0400

Hi,

I learned many specific requirements about industrial field from the
draft. However, my overall feeling from this draft is that it would be
better to seperate routing requirements from the application
description. It provides very nice explanation on application-specific
view, and then ended with very short routing requirements in each
section. So, it makes me feel a bit confused what is the main part of
the draft.

In addition, some explanation of routing requirements sounds a bit
vague for me, such as 'easy to deploy and manage'.

As this is the start of the work, so I'm looking forward to seeing how
it will be progress. :)

Thanks,

-eunah