[6tisch] #35 (architecture): Last call comments: editorial

6tisch issue tracker Tue, 07 Apr 2015 00:08:53 -0700

#35: Last call comments: editorial

 '''Chonggang:'''

· pp. 3, 2nd paragraph, “…control operations such industrial
automation…” ---> ““…control operations such as industrial automation…”
· pp.3, 3rd paragraph, “…timeSlotted Channel Hopping …” --->
“…Time Slotted Channel Hopping…”
· pp.3, 4th paragraph, the fulling spelling of TSN was givning in
the 2nd paragraph. Then, please put the acronym TSN in the 2nd paragraph
· pp.3, both “deterministic” and “Deterministic” are used in a few
places. Better use one form if they mean the same thing throughout the
draft.
· pp.4, 2nd paragraph “Route Computation may be achieved in a
centralized fashion by a Path Computation Element (PCE), in a distributed
fashion using the Routing Protocol for Low Power and Lossy Networks (RPL)
[RFC6550], or in a mixed mode”,
o Is RPL claim to be a distributed route computation? I believe in the
non-storing mode, the root calculates the route and use source routing to
route the packet to the destination.
· pp.4, last two paragraphs from the bottom and a few other place
in the draft, “…neighbor Discovery…” ---> “… Neighbor Discovery…”
· pp. 5, section 3, 1st paragraph, “Some aspects of this
architecture derive from existing industrial standards for Process Control
by its focus on Deterministic Networking, in particular with the use of
the IEEE802.15.4e [IEEE802154e] TSCH MAC and a centralized PCE.”
o What are the “existing industrial standard”? WirelessHart? Certain
references would help.
· pp.6, the title of Figure could be more complete by saying
something like “Figure 1, Basic Configuration of 6TiSCH Network”
· pp. 6, the paragraph under Fig. 1, “neighbor Devices” --->
“neighbor devices”
· pp.6, 2nd paragraph from the bottom, “LLN Border Router (LBR)”
were mentioned twice in one sentence.
· pp.8, Figure 3, suggest changing its title to “6TiSCH Protocol
Stack”
· pp.8, Figure 3, “6LoWPAN HC” shows between IPv6 and 6top. It is
correct but it could imply that only HC is used there – which is not true.
Suggest changing 6LoWPAN HC to something like “6LoWPAN (e.g. adaptation,
header compression)”
· pp.9, the 4th paragraph, “join process” was introduced all of a
sudden. Wonder if it could read more smoothly by briefly mentioning these
concepts (e.g. neighbor discovery, join process, track reservation, 6top,
packet forwarding, etc.) together and their relationship from
architectural perspective somewhere in Section 4 (e.g. at the beginning?).
· pp.9, 3rd paragraph, “TEAS protocol will be required to expose
the device capabilities and the network peerings to the PCE, and a
protocol such as a lightweight PCEP or an adaptation of CCAMP G-MPLS
formats and procedures will be used to publish the tracks, computed by the
PCE, to the devices.”
· Can you put the reference about “TEAS” and “CCAMP”?
· pp.10, 2nd paragraph, “should be portable only other LLN link
types”. It reads a little awkward and maybe some words missing around
“only”
· pp.10, 2nd paragraph, “A new version of the standard is expected
in 2015”. What’s “the standard” refer to?
· pp.10, 4th paragraph, do you want to add a reference for
ISA100.20?
· pp.16, 4th paragraph, “motes” was used. Can we change it to
devices or nodes to make terms more consistent?
· pp.17, 2nd paragraph, “but also allows an upper layer like RPL.”
This sentence seems not finished
· pp.18, 2nd paragraph, “that is is not capable of”. One “is”
should be removed.
· pp.19, the last paragraph, “an higher layer” ---> “a higher
layer”
· pp.19, the last paragraph, “DSCP can therefore be used”. Suggest
giving the full spelling and reference to DSCP or removing this sentence.
· pp.19, 5th paragraph, “A 6TISCH Instance is associated to one
slotFrame.”,
· Wonder what is a 6TiSCH Instance? Why associate to only “one”
Slotframe? In previous paragraph, it mentions “Multiple slotFrames can
coexist in a node schedule”.
· pp.21, section 9, both “Static Scheduling” and “Minimal Static
Scheduling” are used. Are they the same?
· pp.22, 1st paragraph, “This scheduled can be” ---> “This
schedule can be”
· pp.24, section 10.1, 1st paragraph, “A bundle of cells set to
receive (RX-cells) is uniquely paired to a bundle of cells that are set to
transmit (TX-cells), representing a layer-2 forwarding state that can be
used regardless of the network layer protocol.”
· Is a Track uni-directional or bi-directional? Is there any ACK
for the transmission?
· pp.27, Figure 6, suggest adding what is the value “set dmac to”
and “restore dmac”
· pp.27, section 10.1.3, 1st paragraph, “If the tunnel egress
point does not have a MAC address that matches the configuration, the
Track installation fails.”,
· Wonder if it is ingress point or egress point that installs the
Track
· pp.30, 1st paragraph, “Centralized routes can for example
computed”. The word “be” was missing.
· pp.30, section 11, it will be helpful if the difference between
routing discussed in this section and forwarding discussed in section 10
could be clarified a little bit

----

Anand:

There is just one observation which I could not resist mentioning. It has
to do with
the coupling of real-time application demands with the rest of the
architecture. There could be
application specific "time critical and sudden" events that might call for
on-demand resource allocation.
While we can delegate such an event handling to NME and PCE, perhaps,
bringing in an application awareness
to the overall architecture might be useful so that we are not leaving out
this possible scenario.

----

Maria Rita:
pag 8 LLN odes -> LLN nodes
pag. 19 6TISCH -> 6TiSCH
pag 23 as started -> has started
pag 19 in the definition of CDU matrix, I would specify height and width,
and after the timeslot duration (in the current version timeslot duration
is in the middle, and it makes a bit hard to read and clearly understand
the CDU matrix structure)
pag 7 are we sure we want to mention in the next round of the document we
will have evaluated PANA applicability? we may need/want to publish the
second part of the architecture before that, we don’t know yet. So, we
could skip that, if you agree.

----

Rouhollah:

Page 7 first paragraph. LLN odes
Page 9 end of third paragraph. foster

1-Do registration phase may work properly when network builds up, if when
RPL tree grows up and extends like a complete tree (I mean in distributed
manner). Maybe some additional controls needed later?

2-Do you think DICE(figure 3. page 7) should be defined in the Terminology
draft.

Typos:
Page 21. scheduled

----

Guillaume:

1) The term reallocation/relocation of cells :
8.1 p16 a cell reallocation
differs from
9.2 p22 the relocation of a soft cell / relocation is done
=> I am not sure if there has been a discussion on this term, but I vote
for reallocation.

2) 8.2 p16 a set of quality metrics (RSSI, LQI)
I think you cannot be specific to just two metrics (RSSI, LQI).
The words "a set of" allows to define more metrics. And I think it is
fine.
=> what do you think of : "a set of quality metrics (e.g. RSSI, LQI, etc.)
" ?

3) 8.2 p16 and used to compute a Rank Increment
The statistics of 6top may have other usages than incrementing the ranks,
for upper layers, and for resource management.
=> what about : "and used for instance to compute" ?

4) 10.2 p28 : a degree of flow control base on => I think it should be
"based on".

5) (Already pointed out) 11 p 30 Centralized routes con for example
computed => be computed

----

Jonathan Simon:
13 - Sending link-layer frames in the clear in the initial stage of
joining is not providing any benefit. We should always use authentication,
even if the key is not secret, as it provides the ability to reject
similar frames from other 802.15.4-based protocols. It also isn’t
necessary to discuss such a detail here.

13.1 -
* "Triage" - So the JCE decides which nodes are more important and assigns
resources to them first? How? Note this term is not used in draft-
richardson-6tisch-security-architecture-02.
* "arbitrage" should be “arbitrate”

Other than that, it seem to be capturing the overall spirit of the
security architecture and highlights the open areas of security
discussion, e.g. that PANA is an open issue.

Couple minor points:

1) Introduction and 3) Application and Goals sections need review. They
kind of wander all over the place.

5.1) What does "volume" mean in this context? Is this referring to other
as yet defined documents, or later revisions of this document?

----

Rene:
One note: the second para of Clause 13 seems out of place and should be
removed.

----

Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/35>
6tisch <http://tools.ietf.org/6tisch/>

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] #35 (architecture): Last call comments: editorial

Reply via email to