Re: [Roll] Closure text for ticket #86
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 16 April 2012 16:41 UTC
Return-Path: <pthubert@cisco.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 5B05511E80AB for <roll@ietfa.amsl.com>; Mon, 16 Apr 2012 09:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.109
X-Spam-Level:
X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_HI=-8]
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 lLViH1fLg0ze for <roll@ietfa.amsl.com>; Mon, 16 Apr 2012 09:41:42 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C127A11E80AC for <roll@ietf.org>; Mon, 16 Apr 2012 09:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13627; q=dns/txt; s=iport; t=1334594502; x=1335804102; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VxAyiXb4Tp+8QFvyBcml/ezX5fAdwiMMwpqB/RCkB0g=; b=IkDBiS6QeXuRJXExHkQVxlkZCPBEWWkrwemhD8zUw61iJY3G6QC6E/s3 mg/63CABpE5p2axVMofE+dKDjEhs6B0UCAq/zA1kzNLT+02t0k4OVKbiN yvnDpqvFx7/JvBDHipSSQ+dtlxVGt4H9BjDcI8KPQ0fluJtWz8ygbwlsE U=;
X-IronPort-AV: E=Sophos;i="4.75,429,1330905600"; d="scan'208";a="70994592"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 16 Apr 2012 16:41:40 +0000
Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3GGfesX020734; Mon, 16 Apr 2012 16:41:40 GMT
Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Apr 2012 18:41:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Apr 2012 18:40:28 +0200
Message-ID: <BDF2740C082F6942820D95BAEB9E1A8401779AAD@XMB-AMS-108.cisco.com>
In-Reply-To: <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Roll] Closure text for ticket #86
Thread-Index: Ac0b4ZH+VZhhrl3ETEyd9i3UrqArCAADgGqw
References: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu> <843656433.9245.1334588377995.JavaMail.root@mail17.pantherlink.uwm.edu>
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Mukul Goyal <mukul@uwm.edu>, JP Vasseur <jpv@cisco.com>
X-OriginalArrivalTime: 16 Apr 2012 16:41:41.0223 (UTC) FILETIME=[CCE3D770:01CD1BEF]
Cc: roll <roll@ietf.org>, Michael Richardson <mcr@sandelman.ca>
Subject: Re: [Roll] Closure text for ticket #86
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: Mon, 16 Apr 2012 16:41:44 -0000
I'm fine with that... Thanks for the hard work, Mukul; Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: lundi 16 avril 2012 17:00 To: JP Vasseur Cc: roll; Michael Richardson Subject: Re: [Roll] Closure text for ticket #86 Hi all On further thoughts, I think we should defer for the time being using G bit to indicate route discovery priority. There is no real usecase for this at the moment. We can reconsider adding this functionality when we go standards track. So, I propose modifying the resolution text to the following: "The origin always sets the G flag to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an origin MUST always set the G flag to one when initiating a P2P-RPL route discovery. Further, a node MUST NOT initiate a new DAG (with G flag set to zero) if it does not have any parent left in a P2P-RPL DAG." Thanks Mukul ----- Original Message ----- From: "Mukul Goyal" <mukul@uwm.edu> To: "JP Vasseur" <jpv@cisco.com> Cc: "roll" <roll@ietf.org>, "Michael Richardson" <mcr@sandelman.ca> Sent: Tuesday, April 10, 2012 9:51:25 PM Subject: [Roll] Closure text for ticket #86 #86: G flag: do we need that text? Problem ------------------------------ Disagreement on the meaning of 'G' bit and imposed setting to 0; Proposed resolution --------------------------- Add the following text to the draft: "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)." Discussion: ----------------- [Pascal] " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in nature, is created solely for the purpose of P2P-RPL route discovery and MUST NOT be used for packet routing." On the contrary I'd set it to 1. The goal -being to reach the origin- is actually achieved by this DAG. [Mukul] Actually, the DAG is temporary in nature and vanishes after a short while. Even when it exists, it must/should not be used for routing packets back to the origin. So, I think the Grounded flag should be zero. [Pascal2] Please revisit RFC 6650 page 12. G means that a goal is achieved. So first you define the goal and then the bit becomes obvious. What's your goal? Can there be P2P DAGs that achieve the goal and others that make sense to build and yet do not achieve the goal? If you accept that your operation can actually depend on OF logic, then the setting of the goal influences that logic. By forcing a value to the goal in the PTP spec, we actually limit the applicability of the draft. Maybe you can define a default goal and a default setting. But do not MUST that it is set to 0... [Mukul2] When a node joins a temporary P2P DAG, it does not get any additional routing information. The DAG is going to disappear after some time, should not be used for routing while it exists and which nodes end up being on the discovered route is not known until the DRO message comes back. So, I think, by default, the G flag has to be zero. However, if the setting of G flag may affect how an intermediate node may calculate its rank (as per the OF being used), the origin should have the flexibility of setting the flag to 1. So, I could modify the text to say that "the origin sets the G flag based on its perception of how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." [Pascal3] Why do you feel the need to add anything above what RFC 6550 says? I do not see any benefit or additional clarity from doing this. [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page 9, it says "A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data)." This seems to associate the goal with both OF and reachability to certain hosts. Later invocations of the term "goal" seem to refer just to the connectivity aspect, e.g., on page 18 RFC 6550 says "A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal." So, my understanding so far was that the "goal" defines connectivity to a certain hosts. The relation to objective function is not clear at all (if one restricts oneself to reading RFC 6550). The temporary DAGs created in P2P-RPL route discovery provide no connectivity whatsoever to the joining nodes. So, the only reason to set the G flag to 1 would be to allow correct use of an OF. So, I think P2P-RPL spec should use the text I offered above (and repeat below): "The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." What do you think? [Pascal4] If you think this adds value, I will not oppose. Let's keep that as the proposed resolution [Mukul4] Sounds good. Proposed resolution text: "The origin sets the G flag based on its perception of whether joining how the flag's value would affect the rank calculation under the OF being used. By default, the G flag is set to zero given the temporary nature of the DAG being created." [Richard5] I disagree with the proposed resolution. It adds needless confusion. The G flag is 0 if and only if the DODAG is floating. There is no point to allowing floating DODAGs with a P2P-RDO option. I suggest that the G bit be set to 1 and that routers be explicitly prohibited from creating floating DODAGs with a P2P-RDO option. [Mukul5] >The G flag is 0 if and only if the DODAG is floating. I think that the G flag is 1 if and only if the DODAG is grounded. The temporary DAGs used in P2P-RPL are not grounded, they are temporary. I think that all transient/temporary DAGs are floating by their very nature. [Michael5] > I think we need to determine what a grounded DODAG is. > Does it mean that a node announcing such a thing is attached to the > Internet? (In which case P2P usage should G=0) Or does it mean that a > node is attached to the resource named in the DIO? (In which case > origin P2P should G=1) > [Phillip5] The text in 6550 is pretty clear: Goal: The Goal is an application-specific goal that is defined outside the scope of RPL. Any node that roots a DODAG will need to know about this Goal to decide whether or not the Goal can be satisfied. A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data). Grounded: A DODAG is grounded when the DODAG root can satisfy the Goal. Floating: A DODAG is floating if it is not grounded. A floating DODAG is not expected to have the properties required to satisfy the goal. It may, however, provide connectivity to other nodes within the DODAG. The common case of the Goal is "has connectivity to the Internet" but that's not the only case. I think given the Goal for P2P traffic, I agree with Pascal and Richard that it should be 1. [Pascal6] Floating vs. Grounded depends on the goal of the DODAG. I asked you and will ask again what is your goal? If the goal is to reach the root, then G is 1... If you want to signal something to the OF using the G bit, leave it open. [Mukul6] >If the goal is to reach the root, then G is 1... I have told you multiple times that joining a P2P-RPL DAG does not give any sort of connectivity to the node. [Pascal7] I think we disagree because of the definition of goal itself. The goal is an abstraction. Same goes for the term Objective in OF. RFC 6550 only gives examples of what G could be used for but that is not limiting. Certainly the abstraction may for instance mean that external nodes are reachable via the root. But it could be something else entirely. For instance it could designate a root that can aggregate data. In practice, G is used to favor a root that reaches the goal vs. one that does not. But that's senseless for local instances that have by definition a single root. So whatever you set it to does not make a difference for RFC 6550 operations. I figure it could be used for signaling a "transient goal" information to an OF that could use it for a purpose I can't fathom. In any case, as I suggested earlier and as Richard also suggest now, G SHOULD probably be 1 by default but MAY be set otherwise. [Mukul7] Richard wants the flag to always be either 0 or 1. He prefers it to be always 1 but would settle for it being always zero. I think this is not a critical point. I am OK with whatever resolution you and Richard arrive at. Kindly provide me the resolution text I should put in the draft. [Pascal8] I suggest a sentence that says that: 1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. 2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs. 3) the default goal is to create connectivity between origin and target. So by default G should be set to 1. 4) if an intermediate router does not have enough resources to participate to all DODAGs then it should favor DODAGs with the G bit on. The exact wording is yours... [Mukul8] >1) For a local instance there can be only one root and one DODAG. G bit cannot and is not used for DODAG selection within an instance. The statement above seems to be at odds with following two statements >2) In a given deployment, a goal can be defined that some P2P DODAGs achieve and others do not. The roots that achieve that goal will set the G bit in their P2P DAGs. 3) the default goal is to create connectivity between origin and target. So by default G should be set to 1. As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because they use local instance ids. As per statement 2/3, the G flag could be 1 and is 1 by default. I am OK with setting G flag to 1 always (as you, Richard and Phil seem to prefer) but I dont know how to reason this. Do we need to provide a reason at all? [Pascal9] Statement 1 does not say that at all. Can't fathom how you concluded that... Let me try to reword: There is only what DODAG for a given local instance so there cannot be a selection => G cannot be used for a selection that cannot happen. >As per statement 2/3, the G flag could be 1 and is 1 by default. Yes. I added an item to help the device prioritize when it is asker to participate to many DODAGs (for many P2P flows that it happens to be on the path of). In that case, and if the device cannot particpater to all the P2P DODAGs, then the G bit could be use to decide which are the most important. If you define a default goal that the DODAG fills, then you set G to one. For instance, G could mean 'important stuff' like swithing a light on. You'd set it for switching lights but not for reporting the hygrometry of your orchids, which anyway will be retried in a half hour. As a result, if the 2 DAG formations collide, the light on will have precedence... [Mukul9] How about the following text: "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)." [Pascal10] As far as I'm concerned you've captured it and I'm happy with this text. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- [Roll] Closure text for ticket #86 Mukul Goyal
- Re: [Roll] Closure text for ticket #86 Richard Kelsey
- Re: [Roll] Closure text for ticket #86 JP Vasseur
- Re: [Roll] Closure text for ticket #86 Michael Richardson
- Re: [Roll] Closure text for ticket #86 Michael Richardson
- Re: [Roll] Closure text for ticket #86 Pascal Thubert (pthubert)
- Re: [Roll] Closure text for ticket #86 Mukul Goyal
- Re: [Roll] Closure text for ticket #86 Pascal Thubert (pthubert)
- Re: [Roll] Closure text for ticket #86 JP Vasseur