Re: [Roll] RPLinfo review

Ines Robles <mariainesrobles@googlemail.com> Tue, 24 May 2016 08:50 UTC

Return-Path: <mariainesrobles@googlemail.com>
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 6887E12D1A5 for <roll@ietfa.amsl.com>; Tue, 24 May 2016 01:50:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
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 wxnV2KCxkin3 for <roll@ietfa.amsl.com>; Tue, 24 May 2016 01:50:42 -0700 (PDT)
Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C984C12D0BA for <roll@ietf.org>; Tue, 24 May 2016 01:50:41 -0700 (PDT)
Received: by mail-vk0-x232.google.com with SMTP id c189so12823903vkb.1 for <roll@ietf.org>; Tue, 24 May 2016 01:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=rkflsXxoWZbcivEAeYsQcDnVYESzsYUTgKsQxgczWEo=; b=0uTGDlBIRJ41LI5lFvUzuWKutOBT0vFhCQ5Gzr5/ez4w3Y6zQbx5jUCbN/Um9na1dB ShiStsTMrKXQXietAuX6o0/EP10hcCgblX0dwg0BJmizE+yQijyBuVRuzDK/7EYXSiTK 1FcTzfub/NBTpAtTQavJlIvZ25M0zmTrAuJil/hksxO7v/n+aw8vGkbPjQqpcsd0y+Yj 7Ek3q+r/8rn4d9Ivq6wbZVV8Tkv6Tps/RXDxGpP/Xfa8cGJMqEexfPZ6qd2MazZmPCb/ r4v1DTtmiwmi8icNJA727Fo2GCqHrwu6emSu0GZBdZzy0FnizjysAMyGZbSA31VqNPGS /J5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=rkflsXxoWZbcivEAeYsQcDnVYESzsYUTgKsQxgczWEo=; b=PBFteaC57WiUq3ueDDNVSQfgIQmn8s1mzNTEvnptwR2CFQB9QPgDXCsMy5momS7bB0 OupxYaDpyHiq3xQvZAtbWQuTkYu00YBKF68KYS5XhWVn8gjm5KrUDSisCyvfLrRKU892 jy0vjT5FKOMiMzNyNA+sseW23w8P/3635cZlqQByBItdeAX5ZwRO5iqGHTLefgDqYz4p pEryvUmz4VZzWWLzogwRjkU/CJmqK6Ii9XcGyKEFemzpEi1cninEmGPxIbNdHRfuChRb gUd7d7X3JPjgZDUfP1uj2gDc3q/llztcB0YoLDOeELy9sWhNsJBZpXL0Ob4CV3GY8era k4Xw==
X-Gm-Message-State: ALyK8tK++Kax0gP50Cv013Y4oURd/VKKs0wY8jnzwMhcwZ9CYRjb9VJBcJvC25ioFC7FYvpqEIgRXATDv8GLeQ==
MIME-Version: 1.0
X-Received: by 10.31.158.1 with SMTP id h1mr1857839vke.5.1464079840679; Tue, 24 May 2016 01:50:40 -0700 (PDT)
Received: by 10.159.37.98 with HTTP; Tue, 24 May 2016 01:50:40 -0700 (PDT)
In-Reply-To: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl>
References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl>
Date: Tue, 24 May 2016 11:50:40 +0300
Message-ID: <CAP+sJUePiV+_Nd+f-H-x_zNoTgkS0Cqe1rq7qD7ie_H3MyOorw@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=001a11425eecd39e40053392a66f
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/_4h7xhjtV4JV1sXc7uUyl0z6Lpc>
Subject: Re: [Roll] RPLinfo review
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: 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: Tue, 24 May 2016 08:50:44 -0000

Hi Peter,

Thanks for your comments, please find comments below.

2016-05-13 12:14 GMT+03:00 peter van der Stok <stokcons@xs4all.nl>;:

> 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.
>
OK, we are addressing all of above editorial issues

Page 5, line 2: I assume that 6LN is not RPI aware.
>
Yes

> 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.
>

Ok, we will clarify the figure.

I also did not see a mapping of flow from one RPL instance to another
> instance.
>

I do not understand this. Could you please clarify?


> 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.
>

Ok, thanks for the suggestions.


> 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
>

We use 6LN as leaf, and not as router, we are going to clarify this.

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.
>

We are going to clarify the text with your suggestions.

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.
>

The simplest fully general situation for storing mode is to always put in
hop-by-hop IPIP headers.


> 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.
>

Yes, it is hop-by-hop, we will clarify the text.


> Page 13, line 1 Why two fashions: direct root, and hop by hop to root.
>

For direct root, the 6LR can know the address of the root because it knows
the address of the root via the DODAGID in the DIO messages, and In all
cases hop by hop can be used


> Section 5.8
> Can refer to section 5.3 directly, and remove text.
>

I would prefer leave the text for a better understanding.

Many thanks again to help to clarify the draft. :-)

Cheers,

-----------------------------------------------------------------------------------------------------------------------------------------
> 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
>
>
>
>