Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-measurement-06.txt>

"Adrian Farrel" <> Fri, 14 December 2012 11:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD58221F857B for <>; Fri, 14 Dec 2012 03:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.563
X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g4QTg8Y1REv6 for <>; Fri, 14 Dec 2012 03:31:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D8EC121F858C for <>; Fri, 14 Dec 2012 03:31:08 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id qBEBV6iv003349; Fri, 14 Dec 2012 11:31:07 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id qBEBV5Gw003317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Dec 2012 11:31:06 GMT
From: "Adrian Farrel" <>
To: "'Mukul Goyal'" <>
References: <> <>
In-Reply-To: <>
Date: Fri, 14 Dec 2012 11:31:03 -0000
Message-ID: <00c401cdd9ee$80c83260$82589720$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJGmD481w0jIuUDjM0quxi97XqkJZcmqxuw
Content-Language: en-gb
Cc: 'roll' <>
Subject: Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-measurement-06.txt>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Dec 2012 11:31:09 -0000

Hi Mukul,

My confusion (this time ;-) was caused by reviewing draft-ietf-roll-p2p-rpl immediately previous.

Reading that document, it became very clear in my head that there is a difference between "normal" operation of RPL and P2P-RPL. Therefore, it was completely clear [sic] to me that this I-D was for use in measuring routes in P2P-RPL.

Of course, now you point it out (and since I have had a little sleep) is it obvious that this I-D is about making measurements of the traffic path between a pair of nodes in a RPL-operated network.

Maybe my language in that last paragraph might help if you feel charitably inclined. But the whole thing, now it has penetrated the recesses of my cranium, does not require any further work.


> -----Original Message-----
> From: Mukul Goyal []
> Sent: 14 December 2012 01:15
> To: adrian
> Cc: roll
> Subject: Re: ID Tracker State Update Notice: <draft-ietf-roll-p2p-measurement-
> 06.txt>
> Hi Adrian
> I think this comment needs clarification. So, here it is!
> [Adrian]
> ---
> Abstract
> I'm confused :-)
> The document title is very specific to P2P routes. But the Abstract
> (deliberately?) does not mention P2P.
> [Mukul]
> Here is the current title: (I will modify it based on your comment on the meaning
> of the term "quality")
> A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power
> and Lossy Network
> Here is the current abstract:
> "This document specifies a mechanism that enables an RPL router to
>    measure the quality of an existing route towards another RPL router
>    in a low power and lossy network, thereby allowing the router to
>    decide if it wants to initiate the discovery of a better route."
> Now, what is a point-to-point (P2P) route? The draft is written assuming that a
> point-to-point route is a route from one RPL router to another RPL router. This
> route could be a pure source route or a hop-by-hop route along a DAG or a
> mixture (hop-by-hop till DAG's root and then source route there onwards). If we
> agree on this definition than there should not be any confusion. Do you want me
> to include this definition in the draft?
> [Adrian]
>  Section 1 seems to imply that I
> could run the mechanisms on any route from origin to target to see if it
> is good enough - and that would include routes created using normal RPL.
> [Mukul]
> Right.
> [Adrian]
> But section 2 explicitly constrains the mechanism to P2P routes.
> [Mukul]
> I think the following sentence offends you:
> "The mechanism described in this document can be used by an Origin in
>    an LLN to measure the aggregated values of some routing metrics along
>    a P2P route to a Target within the LLN."
> But I immediately clarify what I mean by a P2P route:
> "Such a route could be a
>    source route or a hop-by-hop route established using RPL [RFC6550] or
>    P2P-RPL [I-D.ietf-roll-p2p-rpl]. "
> I think I will replace the term "P2P" in the offending sentence to "existing". This
> should remove the confusion.
> [Adrian]
> Furthermore, the redefined terminology in 1.1 (see below for my
> objection to that!) seem to suggest measuring from an arbitrary origin
> to an arbitrary target regardless of whether a P2P route exists.
> [Mukul]
> We can indeed use the specified mechanism to measure routing metric values
> along an existing route from any arbitrary origin (as long as it is an rpl router) to
> any arbitrary target (as long as it is an rpl router) within the same LLN.
> I think you are assuming that a P2P route is the one established using P2P-RPL.
> This is not the case. A P2P route is a route from one point (RPL router) to another
> (RPL router) and could have been established using RPL or P2P-RPL or any other
> routing protocol.
> [Adrian]
> Can you:
> - unconfuse me
> [Mukul]
> I hope I just did!
> [Adrian]
> - make sure that the abstract and introduction explain the real
>   situation
> - make sure the document title is accurate
> - make sure that the document is consistent
> - be careful with terminology (just because you run the mechanism from
>   A to B in a point-to-point sort of way, doesn't mean that there is a
>   P2P route from A to B)
> [Mukul]
> Or may be there is another definition of "P2P route from A to B" that I am
> missing?
> Thanks
> Mukul