[Roll] RPLinfo review
peter van der Stok <stokcons@xs4all.nl> Fri, 13 May 2016 09:15 UTC
Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0070712D15A for <roll@ietfa.amsl.com>; Fri, 13 May 2016 02:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKrO42Lt-610 for <roll@ietfa.amsl.com>; Fri, 13 May 2016 02:14:54 -0700 (PDT)
Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C5412D133 for <roll@ietf.org>; Fri, 13 May 2016 02:14:53 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.199]) by smtp-cloud6.xs4all.net with ESMTP id tlEr1s00C4Hiz6i01lErmQ; Fri, 13 May 2016 11:14:52 +0200
Received: from AMontpellier-654-1-128-219.w90-0.abo.wanadoo.fr ([90.0.215.219]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Fri, 13 May 2016 11:14:51 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Fri, 13 May 2016 11:14:51 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Roll <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl>
X-Sender: stokcons@xs4all.nl (zCdz/c9tmzVslTdaDKMBkNwWaPqM1Ad8)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/WRmdwFavbThIF3k7ic6v6xBxYYA>
Subject: [Roll] RPLinfo review
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2016 09:15:01 -0000
Dear authors, Thanks for your document. In my opinion the document is very useful. Although many things are well explained, I am still left with questions and possible ambiguities in my understanding. Consequently, my review goes up to section 5.8. Continuing the review becomes more effective when my current questions are answered. Line numbers are with respect to page or to section header; hope this is clear. Below my review: ____________________________________________________________________________ Page 3, section1, line1: the first use of RPL please write in full. Section 2: please provide the reader with a list of terms from RFC7102 that is used in the document. Page 4: ICMPv6 may need a reference? DIS, DIO, and DAO are not provided by RFC7102. Please write in full or provide reference in section 2. Page 5 I like figure 2, and use it as a reference throughout the document. Page 5, line 2: I assume that 6LN is not RPI aware. Page 5: The phrase: “Advertisement, 6lowPAN … network” may need reference to RFC. Page 5 2nd al. write 6tisch in full? Page 5, 3rd al; write LLN in full (first occurrence) Page 6, Figure 3 and architecture text is informative, but please clarify how the use cases of section 4 map to figure 3. For example where does Internet start/end: at border router or at backbone router? And how does flow from one mesh over the backbone to the next mesh map to the use cases. I also did not see a mapping of flow from one RPL instance to another instance. Page 8, line 3: route -> root. Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and RPL-NSM, otherwise explain the meaning of the N. Page 8, Please align terminology of table 1 with terminology of Figure 2 I would suggest to move table 1 and its concluding text to a last summary section of section 5. At the beginning of section 5, the import of the text is far from clear. I would recommend to write down at the beginning of section 5 the characteristics of storing mode for this document; e.g. root and 6lr do not know if a destination is part of RPL DODAG; and thus needs IP over IP header in all cases. Page 9 , section 5.1 line 1: states -> stated Page 9, line 7: is suitable -> is compulsory; or use SHOULD in different kind of phrase “in storing mode …….information”. suggestion to move section to start of section 5 Page9, Line 10: RPL-aware-leaf (6LN) in figure 2 it is called 6LR, I recommend to use 6LR throughout. According to figure 2, 6LN stands for something else. This is relevant for whole section 5. “Note:….root node”. Remove this phrase is already done in section 3. Page9 line13: send -> sends Line14: decrement -> decrements; send -> sends Line 15 arrives to 6LBR -> arrives at 6LBR Line 20: “The RPI header …DIO messages” -> The 6LR recognizes the address of the 6LBR (root?) from earlier received DIO messages, and can thus insert RPI directly in the header. The 6LBR receives the packet and accepts the payload. NB: In the whole document root and 6LBR is freely exchanged. May be good to say something about this in section 3. Section 5.2 Everywhere: 6LN -> 6LR Page10, line 1: insert -> inserts; send -> sends This is weird. According to the intro, 6LBR does not know if destination is a 6LR or a 6LN. In my opinion treatment, described in 5.2 and 5.3, by 6LBR and 6LR should be identical. Section 5.3 Put the alinea “ The question…. To leaf” up front of section 5.3. Section 5.3, Line 3: It includes -> The root (6LBR) uses Section 5.3 line 6: “the header ….node” -> the header before it passes the packet to 6LN. IPv6 is a new term not introduced earlier. Section 5.4 I assume IPv6 node is 6LN. How can the RPI header be encapsulated in the IP-IP header. I thought the encapsulating IPIP header contains RPI. Section 5.4, line 6: process -> processes. Section 5.5 6LN -> 6LR in whole section It would help the reader to explain that 6LR knows the destination is Internet because the prefixes differ. Why should it be done hop by hop? Interoperability requires that it is done in one way. So one IPIP encapsulation with RPI, with encapsulation removed by 6LBR. Section 5.6 6LN ->6LR for whole section Section 5.6, line 4: send -> sent Section 5.6, line 5: When the packet arrives at 6LR, the … Why is this not done in a hop by hop fashion as in section 5.2 modelled on section 5.3, because also here the root does not know whether the destination is 6LR or 6LN node. Page 13, line 1 Why two fashions: direct root, and hop by hop to root. Section 5.8 Can refer to section 5.3 directly, and remove text. ----------------------------------------------------------------------------------------------------------------------------------------- I stop here because I made too many assumptions about the text, and the validity of the rest of the review becomes more and more questionable. I hope this helps; and my misinterpretations may lead to better text. Greetings, peter
- [Roll] RPLinfo review peter van der Stok
- Re: [Roll] RPLinfo review Ines Robles
- Re: [Roll] RPLinfo review peter van der Stok
- Re: [Roll] RPLinfo review Ines Robles
- Re: [Roll] RPLinfo review peter van der Stok
- Re: [Roll] RPLinfo review Ines Robles
- Re: [Roll] RPLinfo review Ines Robles
- Re: [Roll] RPLinfo review Michael Richardson
- Re: [Roll] RPLinfo review Pascal Thubert (pthubert)
- Re: [Roll] RPLinfo review Pascal Thubert (pthubert)
- Re: [Roll] RPLinfo review Ines Robles