Re: [Roll] useofrplinfo version 5

Cenk Gündogan <cnkgndgn@gmail.com> Wed, 06 July 2016 15:14 UTC

Return-Path: <cnkgndgn@gmail.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 B636F12D151 for <roll@ietfa.amsl.com>; Wed, 6 Jul 2016 08:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=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=gmail.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 wjqYdVN5lKWX for <roll@ietfa.amsl.com>; Wed, 6 Jul 2016 08:14:45 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 3148412D091 for <roll@ietf.org>; Wed, 6 Jul 2016 08:14:45 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id z126so115668512wme.0 for <roll@ietf.org>; Wed, 06 Jul 2016 08:14:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DGgEJeyuOzNtaZdbaz6CNncCdB/CRjpBUEwA1wASHWs=; b=AwrB0Q2WinqhNBLWGFKmcDzjOs0HXQDEmNbUOvmtBVbzGObsvaqUYXQKHTv9NlQ+bR gHEs+EKmQZx/E8/pMnfDYD8/2WaLIr96Ud9vEV+DHYFWbm6xPJ/Zec8KMczrBIrwbCGq 9akDlA/JbvgQ1Q6yuvj0h/yLuYl73VizA9Do5P7SNGhE6GlZ2zBBaaXrBHDvWtW3uLXS UHKWzu2DbjuQ6bPq8r9P+tqfqUVa8GRMeDF3fOSpN7hK/b1eebizdRdsFqMlNPpqXxOb HWuIxSRhc1yaMDi9AXsJtjBeO/KS6B5srpGNZBGTBUgsuQhA5rc8/BIUbE6xnzeSrrON 47WA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DGgEJeyuOzNtaZdbaz6CNncCdB/CRjpBUEwA1wASHWs=; b=M42wmDoii7ny4DlWZX1bTzmVcuOvVMMdSMLU6mgRNiKWQwEUSETLiyrMPcUk1ZpjQg B8A5G87WppTukr5BA+PWyjOa5ygZTTPbGLmIeaFdlm1nB/gr6BbQLYGlEG1HAQvYemI1 MuLFlE/NiVQh9Hi/uj/FYDEUXK6j1bVP+pPV+fOBybXnwuHVhmgJqeIq52WBirYzRig8 wTIFnXHuw7WaUlBdqAnPMIdvQvN8KrtAbwi4VzbgfaeoDzAjEDocecOhH5rK36RpFuHv Nt2SaHPcxxS83w0JD54f7o9wfVQKzj/nRf0MkW18FpRSK0GmjTU12mqxdW1XCXZ9cmse 7bBg==
X-Gm-Message-State: ALyK8tIj3LMp5ucD5+A5c7BYDvCadVPqpKw6ET8mdhITCSdrechP4e97T1XhuwNje3dqRw==
X-Received: by 10.28.86.214 with SMTP id k205mr20882897wmb.17.1467818083451; Wed, 06 Jul 2016 08:14:43 -0700 (PDT)
Received: from [192.26.176.176] ([192.26.176.176]) by smtp.googlemail.com with ESMTPSA id i74sm6995686wmg.21.2016.07.06.08.14.42 for <roll@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 08:14:42 -0700 (PDT)
To: roll@ietf.org
References: <b9e569f12a008245ef824e340f510dff@xs4all.nl>
From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= <cnkgndgn@gmail.com>
Message-ID: <e4d82623-86e1-efd7-b813-de4dedb2eaf8@gmail.com>
Date: Wed, 6 Jul 2016 17:14:41 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <b9e569f12a008245ef824e340f510dff@xs4all.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/tz3J0HLefwvLacm1FdGUmk2qTok>
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, 06 Jul 2016 15:14:51 -0000

Hey *,

---
5.3) The question in this scenario is how the root knows how to address
    the IPv6-in-IPv6 header.  It can not know that the destination isn't
    RPL aware, so it must insert an IPv6 header that can be removed on
    the last RPL aware node.  Since the root can not know in a storing
    network where the last RPL aware node is, the IPv6-in-IPv6 header
    must be added hop-by-hop along the path from root to leaf.
---

in section 5.3 it is said that the sender does not know whether the
destinationaddress is rpl-aware or not.
This might be true for P2P traffic, but for root->leaf traffic,
I would expect that the root knows that.

There is the Transit Option for DAOs with the 'E' flag
to indicate that the target address was not learned from rpl.
I would expect that this 'E' flag is set for all Transit Options in DAOs
until it reaches the root node (recursively).
So the root node should actually be aware which
address was learned from RPL and which not.

IMO, the actual problem why we need IPIP is _not_ that the root node isn't
aware whether the destination is rpl aware or not,
but rather that the root node does not know which node the last 
rpl-aware router is,
in case the destination is ~raf.

So, I would suggest to remove the sentence
``
It can not know that the destination isn't
    RPL aware, so it must insert an IPv6 header that can be removed on
    the last RPL aware node.
``

Secondly, Figure 1 is not used like Peter pointed out.
I would suggest to remove this figure, because it is not very
related to the content of this document.

Cenk


On 07/06/2016 02:14 PM, peter van der Stok wrote:
> 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
>
>