Re: [Roll] [RTG-DIR] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 15 January 2013 19:51 UTC

Return-Path: <jmh@joelhalpern.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 3F5E611E809A; Tue, 15 Jan 2013 11:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d79S98oX769y; Tue, 15 Jan 2013 11:51:01 -0800 (PST)
Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6481B11E8099; Tue, 15 Jan 2013 11:51:01 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 164A7A6672; Tue, 15 Jan 2013 11:51:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5E298181116; Tue, 15 Jan 2013 11:51:00 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from [10.10.10.104] (pool-70-106-135-60.clppva.east.verizon.net [70.106.135.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E7015181112; Tue, 15 Jan 2013 11:50:58 -0800 (PST)
Message-ID: <50F5B320.2050108@joelhalpern.com>
Date: Tue, 15 Jan 2013 14:50:56 -0500
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Mukul Goyal <mukul@uwm.edu>
References: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org, rtg-ads@tools.ietf.org
Subject: Re: [Roll] [RTG-DIR] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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, 15 Jan 2013 19:51:03 -0000

Thank you very much.
These changes very nicely address my concerns.  I can understood why you 
chose not to make the one change about route construction restrictions. 
  Your modified text does help that somewhat, without being verbose, and 
I can live with that.

Yours,
Joel

On 1/15/2013 2:43 AM, Mukul Goyal wrote:
> Hi Joel
>
> Thanks for your review. I have made changes to the draft based on your comments. The modified draft can be seen at:
>
> https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-measurement-08.txt
>
> I will include these changes in the new version to be posted at the conclusion of the last call.
>
> Please see my response to your comments below and let me know if the modifications to the draft look OK to you.
>
> Thanks
> Mukul
>
> ----- Original Message -----
>
> Document: draft-ietf-roll-p2p-measurement-07.txt
>
> Reviewer: Joel M. Halpern
> Review Date: 9-Januar-2013
> IETF LC End Date: 21-January-2013
> Intended Status: Experimental
>
> Summary: I have some minor concerns about this document that I think
> should be resolved before publication.
>
> Comments:
>       Generally, this is a well written and readable specification
> addressing an understandable problem.
>
> Major Issues:
>
> Minor Issues:
> ---------------------------------------------------------
> [JH]
>       I had not realized until section 4.3 that NUM (and the structure of
> the message) had to allow for the desired limit on the Address
> Accumulation.  (I had originally inferred a rather painful strategy.)
> Could this be stated earlier in the document please?
>
> [MG]
> Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Sections 2 and 3.
>
> [JH]
>       Can the first sentence of the text in the nested bullet on Source
> Routed Address vectors ("When the Measurement Request is traveling along
> a Source Route...") be moved before the description of the bits  (sorry,
> it may need to be slightly reworded to do so.)  This restriction is very
> helpful in understand the behaviors defined by the various flags in the
> message header.
>
> [MG]
> Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Section 2.
>
> [JH]
> (Also, if it wouldn't bother the ROLL/RPL experts too
> much, a comment about he root not needing to add a source route for a
> local RPLInstance would complete the picture nicely.  I am merely
> inferring this behavior from the fact that accumulate is allowed with
> hop-by-hop and local RPLInstances.)
>
> [MG]
> To respond to your comment, I thought long and hard about including a brief section on global/local RPLInstanceIDs, storing/non-storing DAGs and other such RPL delicacies and then decided against it. I think this document is not the right place
> for such details. The biggest concern was that it would be impossible to keep the section "brief". I think RPL and P2P-RPL documents must be referred to get these details. I did add a tiny bit of text in the Overview Section (see the tags mods_2_...) regarding how Source/Hop-by-hop routes are identified.
>
> BTW, the specific comment you sought would go some thing like this: RPL provides local RPLInstanceIDs to allow routers to create local DAGs. P2P-RPL uses local RPLInstanceIDs in a particular fashion. Under P2P-RPL, a router (the Origin) discovers a route by creating (by acting as the root for) a temporary DAG that is identified by one of the Origin's IPv6 addresses and a local RPLInstanceID. The temporary DAG dies soon after a Source Route has been discovered or a Hop-by-hop Route has been established. Such a Hop-by-hop route, discovered using P2P-RPL, is identified by the same <local RPLInstanceID, Origin's address> tuple that was used to identify the temporary DAG. So, a route discovered using P2P-RPL is always either a pure Source Route or a pure Hop-by-hop route and is never a "mixed" route.
>
> [JH]
>       It appears that the loop prevention requirement on source routes
> requires every router that handles the packet to examine every entry in
> the source route to make sure that the inspecting router does not appear
> anywhere except a the current index entry.  ("MUST ensure that o address
> appears more than once" in section 5.1, and text in section 5.3.)  That
> would seem to be a significant cost, for no obvious benefit.  Why is it
> required?  (Yes, I have read the last bullet of section 9.  This seems
> to be a very expensive set of extra protections.  Given that the index
> gets increment, the cost of a loop seems pretty small.)
>
> [MG]
> You are right. I realized there is no real need for an Intermediate Point to check for loops. I also realized that this check does not always protect against a rogue Intermediate Point modifying the Address vector to insert a routing loop (suppose the nodes that appear multiple times in the modified Address vector wont see this Measurement Request). I have removed from the text this unnecessary check as well as the reference to it in the Security section.
>
> [JH]
>       I section 5.2 and 5.3, how can the processing node determine the
> "Address vector is present in the received message" if the Num field is 0?
>
> [MG]
> Right. The Num value is the only way to tell whether an Address vector is present or not. Corrected the language everywhere.
>
> [JH]
> Nits:
>       Could the first bullet in section 5.1 be re-ordered so that the
> condition ("if it does not know how to reach the End Point") occurs
> before the "MUST discard".  As written, the reader is startled by
> thinking that the first thing the root must do is discard the request.
>       Could the same be done to the second and third paragraphs of 5.2?
>       And the second and third paragraphs of section 5.3?
>       And the second paragraph of section 5.4?  (The third paragraph of
> 5.4 has things in the order which I think is clearer for the reader.)
>
> [MG]
> Done.
>
> [JH]
>       The last sentence of the next to last paragraph of 5.5 could also
> be reversed, although for some unknown reason I find that one less
> bothersome.
>
> [MG]
> OK. I did not change this particular sentence.
>
> [JH]
>       Section 7, second paragraph could also be usefully reversed.
>
> [MG]
> Done.
>
> [JH]
>       I presume that all the "dropped with no further processing" is not
> intended to preclude updating error counters and similar actions.  Is
> there a place that could be said?
>
> [MG]
> Right. Added the relevant text towards the end of Section 3.1 (look for tags mods_3_...).
>
> Thanks
> Mukul
>