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