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

["roll issue tracker" <[e-mail]>]

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

 Problem (resolition is proposed)
 ------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

 Proposed resolution
 ---------------------------
 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.

 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.

 Pascal

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  applicability-ami      |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/86>
roll <http://tools.ietf.org/wg/roll/>