Re: [Roll] [roll] #86: G flag: do we need that text?

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Fri, 13 April 2012 09:01 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
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 5FF1521F877C for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 02:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.405
X-Spam-Level:
X-Spam-Status: No, score=-101.405 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bVouHZL0EOs for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 02:01:31 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5983521F8778 for <roll@ietf.org>; Fri, 13 Apr 2012 02:01:28 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1SIcNj-0004tt-C6; Fri, 13 Apr 2012 05:01:27 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: roll issue tracker <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 09:01:27 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/86#comment:4
Message-ID: <070.004bf738cb1975bfbcf68b6a31b9cc77@trac.tools.ietf.org>
References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 86
In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #86: G flag: do we need that text?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: 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: <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, 13 Apr 2012 09:01:32 -0000

#86: G flag: do we need that text?

Changes (by jpv@…):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Hi Michael:

 I tend to agree that we are somewhat repurposing G... or extending it if
 that's a better word.
 The clear part of G's meaning is related to floating DAGs which is a
 concept that comes with global instances.
 Local instances were defined and reserved in RFC 6550 for use in P2P.
 RFC 6550 did not push as far as locking meaning for the G bit.
 It actually makes sense that the draft that really defines a use of
 local instances also defines what G does in that world.
 And here we thought is that instead of comparing DODAGs within a DAG
 associated to a global instance, G would now be used to compare DODAGs
 that are each a DAG associated to a local instance.
 The semantic shift is that now, G eventually compares the applicative
 value of different apps for a user as opposed to the routing value of
 various DODAGs for an application. We went up a level.
 That's actually not a bad idea since P2P is getting us deeper in the
 world of autonomic networks and thus into higher level abstractions.
 I do not see that there is any opposition in doing it. The wish here is
 that the text must indicate more clearly that we are doing this shift.
 I think that Mukul will provide the additional informative sentence that
 we'd like to see.
 In any case, I see no point in keeping that ticket open. Too much ML
 bandwidth was used on that discussion. Unless Richard speaks up again
 which I doubt, I think we really want the ticket and discussion closed.

 Cheers,

 Pascal


 -----Original Message-----
 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
 Michael Richardson
 Sent: jeudi 12 avril 2012 19:40
 To: roll@ietf.org
 Subject: Re: [Roll] Closure text for ticket #86


 "Richard" == Richard Kelsey <richard.kelsey@ember.com> writes:
 "The origin sets the G flag to indicate the relative importance
 of the route discovery it is initiating. The G flag is set to one
 if this particular route discovery is more important from
 application's perspective than some other route discovery. In
 other words, the origin sets the G flag to one if this particular
 route discovery helps meet the application defined goal
 \cite{rpl}. Thus, the G flag setting helps an intermediate router
 choose which route discoveries to participate in if it cannot
 participate in all route discoveries. An intermediate router
 SHOULD participate in route discoveries with G flag set to one
 (in preference to ones with G flag set to zero)."

    Richard> If you want to repurpose the G flag in this way you need to
    Richard> be clear that the usage in RFC 6550 no longer applies.  I
    Richard> think that the best way to do this would be to say that
    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:

 I would like to understand why you feel that in the P2P case, setting
 G=1 is somehow repurposing the G flag.

    Richard> Not having floating DODAGs would mean that the original use
    Richard> of the G flag is no longer necessary.

 There is no use in floating DODAGs... *for the P2P case*.
 I think that floating DODAGs have many uses in the P2MP case, during
 DODAG construction and repair.

 --
 ]       He who is tired of Weird Al is tired of life!           |
 firewalls  [
 ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
 architect[
 ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
 driver[
   Kyoto Plus: watch the video
 <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                        then sign the petition.


 _______________________________________________
 Roll mailing list
 Roll@ietf.org
 https://www.ietf.org/mailman/listinfo/roll

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/86#comment:4>
roll <http://tools.ietf.org/wg/roll/>