[Roll] [roll] #10: Non supported OF

["roll issue tracker" <trac at tools.ietf.org>]

#10: Non supported OF
--------------------------------+-------------------------------------------
 Reporter:  jpv at …               |       Owner:  wintert at …      
     Type:  defect              |      Status:  new            
 Priority:  major               |   Milestone:                 
Component:  rpl                 |     Version:                 
 Severity:  Active WG Document  |    Keywords:                 
--------------------------------+-------------------------------------------
 Email from JP: (chair hat off)

 We'd like to get your input on the following issue. Referring the
 following text:

 We had that text is -03:

    "RPL is designed to survive and still operate, though in a somewhat
    degraded fashion, when confronted to such heterogeneity.  The key
    design point is that each node is solely responsible for setting the
    vector of metrics that it sources in the DAG, derived in part from
    the metrics sourced from its preferred parent.  As a result, the DAG
    is not broken if another node makes its decisions in as antagonistic
    fashion, though an end-to-end path might not fully achieve any of the
    optimizations that nodes along the way expect.  The default operation
    specified in OCP 0 clarifies this point."

 We changed the text but still some confusion remains so let's try to
 clarify.

 Question 1: should we rely on default OCP/Metric ?

 Option 1: if the OCP/metric is not advertised, the node should use the
 "default" OCP
 Option 2: the OCP/metric must always be explicitly mentioned in the DIO.

 Question 2: OCP/metric not understood/supported.

 Consider the following DAG:

      A
    /   \
  B    C

     X

 X is a new node receiving DIO messages from B and C.

 The question is "What should X do when receiving a DIO specifying an OF
 and metric that it does not understand ?"

 1) Option 1
 X logs the problem and does not join the DAG at all.

 2) Option 2
 X logs the problem, joins the DAG selecting either B or C as a "leaf"
 (randomly since it does not understand the metric or the OF). The idea of
 joining as a leaf is that X should not start advertising DIO with
 inconsistent metric (that could confuse many other nodes behind).

 3) Option 3
 X joins and tries to advertise "some" metrics trying to provide
 connectivity for more other nodes.

 I personally favor 2).

 Opinions ?

 Thanks.

 JP.

 CONCLUSION
 The WG seems to convergence of both option 2 above.

 RPL -05 text to be adjusted:

 => The DAG metric Container MUST include an OF
 => The document specify one OCP (OCP0), let's no longer call it the
 "default" OCP
 => Add if a node receives a OF that it does not understand/support, it
 SHOULD log the problem (add it to the manageability section). It SHOULD
 join the DAG selecting a parent as a "leaf" (randomly since it does not
 understand the metric or the OF). The idea of joining as a leaf is that
 the node should not start advertising a DIO with inconsistent metric (that
 could confuse many other nodes behind).

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/10>
roll <http://tools.ietf.org/wg/roll/>