Hello Eric : )
Many thanks for your kind review.
Please see below
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Pascal,
>
> Thank you for the hard work put into this document. It is extensive and
> comprehensive. I really appreciate this well-written document as it is clear
> (albeit long...), so, the COMMENTs and NITs are to improve the document
> quality and not as a negative criticism; your reply + comments will be welcome
> though.
>
> Regards, Bien à toi,
>
> -éric
>
> == COMMENTS ==
>
> -- Section 1 --
> Suggest to be more specific about the backbone: layer-2 or IP backbone ?
When a backbone router is used top proxy ND, then it is a L2 backbone.
The architecture allows a more complex routed structure, if the backbone router
redistributes in a routing protocol, e.g., using a L3 fat tree.
I guess it does not hurt to add a sentence that clarifies this.
proposal:
before <
6TiSCH provides large scaling capabilities, which, in a number of
scenarios, require the addition of a high-speed and reliable backbone
and the use of IP version 6 (IPv6) [RFC8200]. The 6TiSCH
Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to the
constrained media and RPL [RFC6550] for the distributed routing
operations.
The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model
that is composed of a federating backbone, e.g., an Ethernet bridged
network, and a number of IEEE Std. 802.15.4 TSCH low-power wireless
networks federated and synchronized by Backbone Routers.
>
After <
The 6TiSCH Architecture relies on IPv6 [RFC8200] and the use of
routing to provide large scaling capabilities. The addition of a
high-speed federating backbone adds yet another degree of scalability
to the design. The backbone is typically a Layer-2 transit Link,
e.g., an Ethernet bridged network, but it can also be a more complex
routed structure.
The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model
that is composed of a federating backbone and a number of IEEE Std.
802.15.4 TSCH low-power wireless networks federated and synchronized
by Backbone Routers. If the backbone is a Layer-2 transit Link then
the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6
ND) [RFC4861] proxy.
The 6TiSCH Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to
the constrained media and RPL [RFC6550] for the distributed routing
operations.
>
--------------
>
> -- Section 2.1 --
> Please define 'PAN' before first use.
PT> Removed, was not so useful where used.
> The choice of 'ASN' in an IETF document was probably not the choice... ;-) I
> was
> unable to understand the concept and use of layer-2 bundle by reading the
> definition. Let's hope it is defined/explained later... It is probably too
> late to
> change now, but, this section is really too heavy and by alphabetical order,
> so,
> its usefulness is reduced for first-time readers. Section 3 is rather easy to
> read
> for similar explanations.
PT> Agreed. This is an IEEE term... no choice there. Updated definition to
indicate that:
ASN (Absolute Slot Number): Defined in [IEEE802154], the ASN is the
total number of timeslots that have elapsed since the
Epoch Time when the TSCH network started. Incremented by
one at each timeslot. It is wide enough to not roll over
in practice.
> -- Section 3.2 --
> For my own curiosity, reducing mcast is always good of course but not critical
> on the backbone if it is wired Ethernet. So, why mentioning this fact in this
> memo?
PT> Arguable. If you consider modern fabrics with overlays, mcast is really
detrimental.
Even in flat networks, ARP/ ND related cast is one of the reasons why subnets
can't scale beyond certain numbers, I'm hearing in the 10K order.
For a large factory we are aiming towards a goal of 100K nodes.
Also if the hop to the BBR is wireless, e.g., the BBR is an IOT gateway that
connects to the backbone with Wi-Fi; and that hop would suffer from mcast.
Not sure you're asking for text though so I'd rather leave as is unless you
hint me otherwise.
> -- Section 3.4 --
> Minor inconsistency between the list of the schedule management ways and the
> enumeration. Nothing critical though but confusing.
PT> fixed
>
In "Neighbor-to-Neighbor
> Scheduling", perhaps replace "between adjacent routers" by "between adjacent
> peers" as the text is mainly about peers?
PT> agreed
>
> -- Section 3.6 --
> It is probably useful to define what "feasable" means in the context of this
> memo.
PT> "Feasible Successor" comes from the art of Distance Vector from which RPL
inherits, namely JJ Garcia Luna Aceves 's DUAL.
DV has a feasibility condition, that determines that the peers's distance is
such that if I give him the packet then I will not see the packet again because
the game of distance does not permit.
In short a feasible successor is a router that is closer to the destination
than this node has ever been and advertised. Maybe I should avoid the term if
it creates confusion ?
PT> Note: Juliusz wrote a great explanation of the how here
https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-14#section-2.4
Probably too late in the publication process to change, but, I would
> suggest to use "6LoWPAN Fragments Forwarding" (plural) of even "6LoWPAN
> Fragments Chain Forwarding". More a nit but can you re-use the same names in
> the table at the end of the section? This table should also have a number
> such as
> Table 1
>
PT> I like your proposal. Sadly it impacts 2 other drafts which are also passed
WGLC, https://datatracker.ietf.org/doc/draft-ietf-6lo-minimal-fragment/ and
https://datatracker.ietf.org/doc/draft-ietf-6lo-fragment-recovery/ so yes, it
is really late.
> -- Section 3.7 --
> Figure 4 mentions "to be IEEE Std. 802.15.12"... this is a hint to a IEEE work
> which should be explained in the text or be removed.
PT> Removed, we'll see how 802.15.12 fares
> -- Section 3.8 --
> The first paragraph would benefit if it was clear that it is about
> "*difference* between information and data models".
PT> reworded to
"
Section 2.1 provides the terms of Communication Paradigms and
Interaction Models, in relation with "On the Difference between
Information Models and Data Models" [RFC3444].
"
> Please define what "duocast" is ;-)
PT> done; the text now reads:
"
Additional considerations on Duocast - one sender, two receivers for
redundancy - and its N-cast generalization are also provided.
"
> -- Section 4.1.2 --
> Its title is just in the reverse order of the previous sentence :-O And,
> should it
> mention "colocated" ?
PT> reversed, it certainly reads better. I added a last sentence to the
paragraph below to explain c=what happens when they are not co-located:
"
Section 5 of [I-D.ietf-roll-unaware-leaves] details how the DAO
messages are used to reconfirm the registration, thus eliminating a
duplication of functionality between DAO and EDAR/EDAC messages.
[I-D.ietf-roll-unaware-leaves] also provides the protocol elements
that are needed when the 6LBR and RPL root functionalities are not
co-located."
>
> -- Section 4.2.2 --
> Is there a difference between "IPv6 ND" in figure 5 and figure 6? It is
> followed
> by "NA" "NS" in the latter.
PT> Sorry, I'm not following. I can remove" IPv6 ND" and add a more informative
unicast vs mcast.
| RS (mcast) | | |
|-------------->| | |
|-----------> | | |
|------------------> | |
| RA (unicast) | | |
|<--------------| | |
| | <once> | |
>
> -- Section 4.3.3 --
> Please define "ETX" and "LQI" ?
PT> done
> -- Section 4.4 --
> Is it on purpose that there is a lot of overlap with section 3.4 ?
PT> That's the 2 documents in one that strikes back. You are suppose to read
4.4 separately as the more refined architecture. So yes, we wanted that section
self complete, and still we wanted text in section 3 about it.
> -- Section 4.5.3 --
> Is it worth to define "PRE" or is DetNet knowledge assumed?
PT> Expanded to Packet Replication and Elimination
> -- Section 4.6 --
> Please be consistent with the naming of the sub-sections wrt "three different
> forwarding model"
>
PT> fixed
> -- Section 5 --
> Please replace "This specification" by "This document" as it is not aimed to
> be a
> Proposed Standard.
>
PT> Yes, which never stops to cause me problems, like downrefs in other
documents pointing on this.
> -- Section 6 --
> "ASN" was not fully described before (except briefly in terminology section),
> so,
> I find it weird to build the security section around this concept; moreover,
> as it
> comes from DetNet, I would assume that the DetNet documents are more
> suitable to have this security discussion (with just a point in this memo).
PT> ASN comes from TSCH defined in IEEE std 802.15.4, and is a key element to
the MAC security, since it participates to the nonce.
For that reason, we had to add text there. This is actually the result of a
long discussion with SEC DIR.
But I do not worry: I believe that a person who works on 6TiSCH is familiar
enough with TSCH and ASN that we should be safe.
> == NITS ==
>
> -- Section 1 --
> A comma is probably needed before "Industrial Automation Control Systems
> (IACS)". Same section could possibly also introduce the 'IT' acronym.
> s/require
> the addition/requires the addition/ ? s/, e.g., an Ethernet bridged network,/
> (e.g. an Ethernet bridged network)/
PT> thanks : )
>
> -- Section 2.1 --
> s/: : /: /
>
> -- Section 3.2 --
> s/RPL network needs to share information/RPL network need to share
> information/ ?
>
> -- Section 3.7 --
> s/aloha/Aloha/ ?
> The sentence "The reference stack that the 6TiSCH architecture presents was
> implemented and interop tested" would benefit from a couple of commas.
>
> -- Section 4.3.1.1 --
> Duplicate line.
> Duplicate line. ;-)
>
> - Section 4.6 --
> s/three different forwarding model, /three different forwarding models: /
>
PT> all handled, many thanks!
I'l be publishing this together with Mirja's and Roman's review comments,
hopefully tomorrow.
All the best,
Pascal
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
