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/>
- [Roll] [roll] #86: G flag: do we need that text? roll issue tracker
- Re: [Roll] [roll] #86: G flag: do we need that te… roll issue tracker
- Re: [Roll] [roll] #86: G flag: do we need that te… Richard Kelsey
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Pascal Thubert (pthubert)
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Richard Kelsey
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Richard Kelsey
- Re: [Roll] [roll] #86: G flag: do we need that te… Pascal Thubert (pthubert)
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Michael Richardson
- Re: [Roll] [roll] #86: G flag: do we need that te… Philip Levis
- Re: [Roll] [roll] #86: G flag: do we need that te… Pascal Thubert (pthubert)
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Pascal Thubert (pthubert)
- Re: [Roll] [roll] #86: G flag: do we need that te… Mukul Goyal
- Re: [Roll] [roll] #86: G flag: do we need that te… Pascal Thubert (pthubert)
- Re: [Roll] [roll] #86: G flag: do we need that te… roll issue tracker
- Re: [Roll] [roll] #86: G flag: do we need that te… roll issue tracker
- Re: [Roll] [roll] #86: G flag: do we need that te… roll issue tracker
- Re: [Roll] [roll] #86: G flag: do we need that te… JP Vasseur