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

Mukul Goyal <mukul@uwm.edu> Fri, 14 December 2012 01:14 UTC

Return-Path: <prvs=688ae4962=mukul@uwm.edu>
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 1D03D21F8ADA for <roll@ietfa.amsl.com>; Thu, 13 Dec 2012 17:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 3O7a72ROielI for <roll@ietfa.amsl.com>; Thu, 13 Dec 2012 17:14:58 -0800 (PST)
Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6D95021F888E for <roll@ietf.org>; Thu, 13 Dec 2012 17:14:57 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0EAKF8ylB/AAAB/2dsb2JhbABFhji4UYMYI1YbGgINGQJZBogmqiSKAYkJgSKLUYMUgRMDiGCNKZBIgxKCAw
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 68891121DCC; Thu, 13 Dec 2012 19:14:56 -0600 (CST)
X-Virus-Scanned: amavisd-new at
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hazLB4Om+Vpe; Thu, 13 Dec 2012 19:14:56 -0600 (CST)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 38348121DF4; Thu, 13 Dec 2012 19:14:56 -0600 (CST)
Date: Thu, 13 Dec 2012 19:14:56 -0600 (CST)
From: Mukul Goyal <mukul@uwm.edu>
To: adrian <adrian@olddog.co.uk>
Message-ID: <789414096.115791.1355447696131.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <20121205130341.22852.76100.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: roll <roll@ietf.org>
Subject: Re: [Roll] ID Tracker State Update Notice: <draft-ietf-roll-p2p-measurement-06.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: Fri, 14 Dec 2012 01:14:59 -0000

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