Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-architecture-24: (with COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

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