#36: Last call comments: MCR comments
If it is going to proceed in volumes (I suggest "editions" is the correct
term), then I think that most things which are speculation should either
be removed to a later edition, or something specific should be said, with
the understanding that it might change later. Presciption rather than
speculation should be the goal.
1) I find it odd that there is so much emphasis of the backbone router
function... IN THE ABSTRACT. I suggest that the last sentence: Backbone
Routers perform proxy Neighbor Discovery operations over the backbone on
behalf of the wireless devices, so they can share a same subnet and appear
to be connect= ed to the same backbone as classical devices. be removed
from the abstract. Probably by the end of this review that I'll suggest a
different thing that could be included.
2) end of section 1, what does it mean: "in the round of this document."?
3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability] will
ever get published. If there is terminology there that we still need, I
think it should be extracted into the 6tisch-terminology document. While
it is an informative reference, the fewer references to IDs the better in
my opinion.
4) section 4, seems to ignore the possibility to simply run RPL across the
subnet backbone. I understand why the ND mechanism are nice, because they
permit the backbone to just be ethernet, but the case where the backbone
is really dedicated (and given VLANs, it's hard to know why you'd do
anything else), one can just run RPL across it. I think that this
ultimately matters to any of the later architecture, but I wouldn't want
to later argue with someone who might claim that the newer ND mechanisms
are REQUIRED.
5) the security words include: "will be studied in the next round of this
document." and I'm not sure what a reader should make of this. Perhaps it
should simply summarize section 13 in one sentence and say that PANA is a
possibility, but that the choice of protocol is out of scope for this
document. (well, 5.0 then explains about volumes. So perhaps the
explanation about volumes should go much earlier, most probably into the
abstract as well. Also, will the volumes build on the previous work, or
will they replace it? if they will replace it, then I think correct word
is "edition")
6) I don't think that the Note: about DETNET really still belongs in a
document that might be read in 5-10 years. Maybe a reference to the
charter for DETNET would make more sense.
7) I don't understand why PANA lives above ACE in figure 3. I think that
ACE lives above CoAP/DICE (DTLS is missing, but perhaps understood by
DICE). I think that while technically PANA lives on top of UDP, there is
of course a layer of EAP, and TLS above it, and perhaps a layer of ACE as
well. So I'm not saying that this picture needs to be changed, just to
observe this.
8) I think remove: "COMI and the dependent specifications are still work
in progress, but getting stable enough at the time of this writing."
9) I am happy with the paragraph on join security in section 5.
10) I think that this is confused (bottom of page 9, section 6):
This architecture expects that a 6LoWPAN node can connect as a leaf to
a RPL network, where the leaf support is the minimal functionality to
connect as a host to a RPL network without the need to participate to the
full routing protocol. The support of leaf can be implemented as a minor
increment to 6LoWPAN ND, with the additional capability to carry a
sequence number that is used to track the movements of the device, and
optionally some information about the RPL topology that this device will
join.
I think that either a minimal RPL permits leaf attachment OR the EARO
6lowPAN ND. I don't think that both are needed?
I'm also think that some may confuse this with the join process
requirements, which maybe this started out describing, but I don't think
that does that. It might describe how nodes which have already joined
(been imprinted upon the newtork) can form a network.
Figure 4 seems to do it all without RPL, even though RPL is mentioned, and
I don't understand that.
11) Reading section 6.1/6.2, I wonder if this just too much detail for an
architecture. I also don't see how VLANID is involved (we are talking
802.1q here, right?). I am not saying that the TID and EARO aren't good
things; I'm just finding that they just JUMP out here, and I'm not sure a
reader has any idea why they are here yet. I think that 6.3 should be far
more specific: proxy-ND? LISP? or MIPv6? which is going to be used... I
think that reviewers will push back here a lot.
12) I think that 6.4 needs be prescriptive, not speculative/suggestive.
6.5 needs to say, "the 6LBR and RPL root functionality are to be co-
located in order that the address of the 6LBR be indicated by RPL DIO
messages"
13) I think that 6.6 is saying that SEND can not be applied. I think it
should be clearer in saying something like: "The threats against IPv6 ND
as described in RFC3971 apply as well, but the solution can not work as
the route over network does not permit direct peer to peer communication.
As can be seen in Figure 4..."
14) I think that the relevant parts of [I-D.ietf-roll-rpl-industrial-
applicability] need to imported into this document, since this sure looks
like a normative reference to me.
15) section 8 seems to be really the key aspects of the architecture. I
think that rather than say, "if the scheduling entity explicitely..." =3D>
"hard". I think that it should instead say that there are hard cells and
soft cells, and say that 6top can not move hard cells. (but, how would the
PCE set them up, if 6top can't move them?)
"6top contains a monitoring process which monitors the performance of
cells, and can move a cell in the TSCH schedule when it performs bad."
this seems pretty important an architectural thing, and I think it at
least deserves it's own section number.
16) 8.2, insert something to the effect: Most RPL Objective Functions
require metrics about reachability, such as the ETX. 6top creates and
maintains an abstract neighbor table, and this may be leveraged. ... This
information ...
" 6top also enables the RPL OF to influence the MAC behaviour, for
instance by configuring the periodicity of IEEE802.15.4e Extended Beacons
(EB's). By augmenting the EB periodicity, it is possible to change the
network dynamics so as to improve the support of devices that may change
their point of attachment in the 6TiSCH network. "
But, we aren't using the Enhanced Beacons (they are enhanced, not
extended, aren't they? or did I get that backwards again?) for production
network use...
I would write: Consideration was given towards finding a way to embed the
Route Advertisements and the RPL DIO messages (both of which are
multicast) into the IEEE802.15.4e Enhanced Beacons. It was determined that
this produced undue timer coupling among layers, that the resulting packet
size was potentially too large, and required it is not yet clear that
there is any need for Enhanced Beacons in a production network.
[and then go on to explain how to configure the LinkType, however, I think
that this is too much detail for the architecture, and it needs to say
something like: The 6TISCH adaptation document will explain the details of
confuring a broadcast channel that can accomodate EB, RPL DIOs and Router
Advertisements ]
but, maybe I mis-understand the entire section.
17) I think that 8.3 should actually say how the TSGI should be created,
and also how the various layers can be synchronized such that the RPL
management traffic can provide for the needed frame-based synchronization.
I expect that this simply means that 6top needs to be able to
trigger(override) the trickle timer if no other traffic has occured in
"too long" a time.
"After consultation with IEEE authors, it was asserted that 6TiSCH can
make a full use of the octet to carry an integer value up to 0xFF."
-> does this need some kind of clear liason statement?
I think that the concepts introduced in section 6.4 and 6.5 should perhaps
be more clearly. While not trying to duplicate the terminology document, I
found the way that the CDU concept is introduced was awkward. Perhaps this
isn't very important. Maybe moving figure 5 earlier?
18) I think that the 4 scheduling paradigms should be mentioned in the
introduction as well! To first order, I think that is perhaps the most
important thing in the document.
" If the size of a bundle is configured to fit an average amount of
bandwidth, peak emissions will be destroyed."
(I don't think the word you want is "destroyed". I think that it means
that packets will be dropped, but I don't think that describing the
dropped packets as destroyed is the correct IETF idiom here, even though
it might be grammatically correct)
19) 6TiSCH supports three different forwarding model, G-MPLS Track
Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding
(6F).
also should be mentioned in the introduction...
20) last comment on section 13. (the bullet (*) has become an ASCII "A",
the high bit was likely removed)
Device Authentication: The JN and the JA mutually authenticate each other
and establish a shared key, so as to ensure on-going authenticated
communications. This may involve a server as a third party.
I again say that this is incorrect, the JA will never be able to
authenticate itself to the JN. It may be able to present some
authorization from the network owner, that the JA is authorized to act on
behalf of the network owner.
Unless you consider un-authenticated DH exchange "authentication", or you
decide that it's okay for the JA to just not accept any public (some kind
of leap of faith), the JA will not have an identity that a JN will accept.
I have also repeatedly complained that figure 10 is inaccurate, because it
fails to depict that authorization begins before authentication finishes.
Perhaps the second two unidirectional arrows are part of the
authentication phase, I don't know.
I suggest that the sentence:
"The join protocol consists of three phases:"
be replaced with:
"The join protocol has three major activities:" ("phases" implies some
ordering such that one phase might finish before the next begins, while
activities implies no such ordering)
I suggest that figure 10 be omitted.
--
-------------------------+-------------------------------------------------
Reporter: | Owner: draft-ietf-6tisch-
[email protected] | [email protected]
Type: defect | Status: new
Priority: major | Milestone:
Component: | Version:
architecture | Keywords:
Severity: In WG Last |
Call |
-------------------------+-------------------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/6tisch/trac/ticket/36>
6tisch <http://tools.ietf.org/6tisch/>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
