Re: [Roll] useofrplinfo version 5

Ines Robles <mariainesrobles@googlemail.com> Wed, 13 July 2016 09:35 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 4FC3F12D69F for <roll@ietfa.amsl.com>; Wed, 13 Jul 2016 02:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OAZlOFU2_aZ9 for <roll@ietfa.amsl.com>; Wed, 13 Jul 2016 02:35:14 -0700 (PDT)
Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) (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 AB58012D0E7 for <roll@ietf.org>; Wed, 13 Jul 2016 02:35:14 -0700 (PDT)
Received: by mail-vk0-f42.google.com with SMTP id v6so57275031vkb.2 for <roll@ietf.org>; Wed, 13 Jul 2016 02:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PtOihCXcGi4X7WmskMnGaHAQurLan6p2A5BhBk4E8Es=; b=hA9MXmy3KErxXbU/bExoUHvGU1jQWdccI5SWsANh/0Z+v4yxu+jgaVZXD3z6ZtNHV/ IBbt1AeV0K0V3AB168Uv8yACqXKHbyRMwCXURsVYVAo/CvwPRQfrlPVo+vJjrDwrRFR1 X2qtahJwS6n7dYsFl9j3lxNgIMDh+mqT4G4sgvRFgES+QrihAWL7TqH/xxBJA9aa4Vk1 S7d5VxQL0lVtiKYl22+xnG6U20RIzmXVvoJ8lnr/UVvpqvwWH2ZCwmyOX7nPhk+asUsh kVfSf1WFzCH4Hp0MYXNO2eMgtFa0bQfbQ5AKrK9oc2IA0jIB5URKqQptMEzyst4BcY2T MgWQ==
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:from:date :message-id:subject:to:cc; bh=PtOihCXcGi4X7WmskMnGaHAQurLan6p2A5BhBk4E8Es=; b=HH6Rs66psz7NPJJgr70NStem65oWGa/w65MOEMnirByRlkix0UVXQxi7nZzKDpkIOk aewgkZNaGrnRNNwjcjL0yeU2q0raGbHQv97PNodh9D49D+4Hs6s8xcxyK2fc+XQhf16e 2l1LEOf+ABDgdYwTim4KVnsEfAWul0jaLZi8zHNEdqA+/4gc3ym0Xa962cdQf9DGkzzl 1Mf+ZccqkhYFw41QxjGHfND+JkqS7bB8JlLkzGFv4YDlTp0Va0TqOb9mx7S6RQD4EzFg KNkaEfT24DVVbDie8hgVkyqID4Qu8BLFtbv0DujSxqydi4bgOdp08EnIhjbo5TCljkPa M+Jg==
X-Gm-Message-State: ALyK8tJXz7C5w+7+cvKTrA+6Besi/ED2LoEZgrv1Xbo64+XchFUfp0yQEC27z0uZ6Q8JLM9NRZu4PUv7l5SeEQ==
X-Received: by 10.176.65.71 with SMTP id j65mr3421548uad.103.1468402453704; Wed, 13 Jul 2016 02:34:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.36.241 with HTTP; Wed, 13 Jul 2016 02:34:13 -0700 (PDT)
In-Reply-To: <b9e569f12a008245ef824e340f510dff@xs4all.nl>
References: <b9e569f12a008245ef824e340f510dff@xs4all.nl>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Wed, 13 Jul 2016 12:34:13 +0300
Message-ID: <CAP+sJUdq=sTA5XW4wX5NAoNor+sBv0HMjV1dXG63ffh=1EOCHQ@mail.gmail.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c124708a3fa9a05378116c2
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/U5xRsSiHniB4eRVr_l5HAEjWg9Q>
Cc: Kovatsch Matthias <kovatsch@inf.ethz.ch>
Subject: Re: [Roll] useofrplinfo version 5
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: Wed, 13 Jul 2016 09:35:17 -0000

Thank you very much Peter for your comments,

We are going to address the nits/typos in the next version

About your questions.

P: Section 5.3 and section 5.2: If the 6LBR does not know whether
destination is Raf or not_Raf in section 5.3, then this is also the case in
section 5.2. Question why is the IPv6-in-IPv6 header not also used in
section 5.2. The problem for the 6LBR is the same.

-Thanks for the correction. Here, the text should say: "6LBR knows that the
destination is not_Raf". We have to describe how 6LBR does know it. We need
help in here.

The 6LBR knows when a node is raf, since the downward route is built with
DAOs.

What do you think?

-Other question: how does the last 6LR know that the next node is a not_Raf?

thank you very much to Cenk for answering this. as he said, it would be
good to have more comments on that.

Cheers,

Ines.


2016-07-06 15:14 GMT+03:00 peter van der Stok <stokcons@xs4all.nl>;:

> Hi Authors,
>
> Below my review of the document.
>
> Although the subject is tedious, the draft looks important to me to assure
> inter-operability between implementations
>
> This version was much more readable than the first one. So, I mostly
> signal nits and typos.
> It is important that someone with more implementation experience also
> carefully reviews the document to signal missing text.
>
> Below my comments,
>
> Peter
>
>
> ______________________________________________________________________________________
>
> Review of RPLinfo version 05.
> Intro, last line, change to: “… type 3 {RFC6554], an efficient IP-in-IP
> technique, and use cases …”.
> Section 3, Figure 1 is not referred to in the text.
> Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed by
> the phrase “The numbers …”
> Page 5, line 3: leaf -> leafs
> Page 5, line 7: “is mentioned as well as” -> “is often named”
> Page 6, figure 3 is not referred to.
> Page 7, phrase 2, “This is a fundamental” -> “A fundamental”
> Page 8, line 8,”to add to remove” -> “to add or remove”
> Page 8, line 22, “In tables” -> “In table 1”
> Page 8, line 25, complete -> extensive
> Section 5, phrase 1 change to: “In storing mode (fully stateful), the
> sender cannot determine whether the destination is RPL-capable and thus ….”
> Section 5, line 9, indicates when (when to be added)
> Page 9, last line; don’t understand: “and are the RPL root node.”
> Page 10, line 6: remove: “in order to be able to”
> Section 5.2, line 3, insert -> inserts; send ->sends
> Section 5.3 and section 5.2: If the 6LBR does not know whether destination
> is Raf or not_Raf in section 5.3, then this is also the case in section
> 5.2. Question why is the IPv6-in-IPv6 header not also used in section 5.2.
> The problem for the 6LBR is the same.
> The text in section 5.3 seems to suggest that at each 6LR the IPv6-in-IPv6
> is removed and then re-added again. I would expect the row re-added headers
> be filled in under 6LR.
> Other question: how does the last 6LR know that the next node is a not_Raf?
> Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers to
> the following sections 5.x
> Section 5.8 and section 5.6; same question as for section 5.3 and section
> 5.2.
> Section 5.9, line 11, sending 6LN to (“6LN to” added)
> Section 5.10, line 4, remove “sends”
> Page 16, “Alternatively, …. Compress.” I miss a lot of context to
> understand this paragraph.
> Section 5.11, line 5, addresses -> addressed
> Section 5.11, line 6, subject of “must send” misses.
> Section 5.12, The phrase “The IP-in-IP header must be addressed on a
> hop-by-hop basis” suggests that the header is removed and re-inserted at
> every hop. Nevertheless, that is not mentioned in the accompanying table.
> This is the same question I have for earlier sections 5.x.
> Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the
> destination!
> Section 6.2, “the traffic originates with an RPL aware node”. What do you
> mean? 6LBR is RPL aware? The destination is known to 6LBR because
> destination is RPL aware? Or something else?
> Section 6.3, My interpretation: In 6LBR the RH3 is added and modified in
> each consecutive 6LR until it is fully consumed and removed in the last 6LR.
> Section 6.3, You cite several alternatives. I suggest to only mention the
> solution without RPI.
> Section 6.5, line 3, remoted -> removed
> Identical to storing mode case (please mention section).
> Section 6.6 same remark about RPI as section 6.3
> Sections 6.7 – 6.12, Here you use 6LN for not-RPL aware node, while in
> earlier section 6.x you use IPv6 node. Why?
> Section 7.1, line 6, stiaution -> approach
> Section 7.1, line 10; what is a “single code path”?
> Section 7.2, line 1, This -> In
> Section 7.2 line 3, all DODAG nodes, (added DODAG)
> Section 7.2, line 12, “intermediate 6LN nodes” should be “intermediate
> IPv6 nodes”? If not, I don’t understand the phrase.
> Section 7.2, line 20, there are -> there is
>
>
> --
> Peter van der Stok
> mailto: consultancy@vanderstok.org
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>