Subject: Re: [Roll] Make OCP part of DIO base object or make DODAGconfiguration mandatory for all DIOs

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Wed, 1 Dec 2010 17:38:23 -0800

Sorry for the late reply, was down with viral.
Summary so far:
- There's a configuration error if *any* of the configuration values
differ between the two nodes. Should all of them be in the DIO? Example
DIOIntDoubl. Set to 0.
- "LBR2 sends DIO with config option, Node fails to match OCP and
rejects DIO"
Where in the specification does it say that a node rejects the DIO in
this case and discards it?
- What if the two roots in your example include different routing
metrics in the Metric Container? I guess the metrics in use also
characterize the dag just like OCP. Perhaps, one can identify other
parameters that characterize a dag but are not there in the DIO base
object.

All good points. There are 2 types of misconfigurations - node specific
and network wide.
- misconfigs of configuration values like DIOIntDoubl can be easily
detected and blocked at a node (root of DODAG). This is a node specific
misconfig. Lets take a look at different config options in DIO:
  -
DIOIntDoubl./DIOIntMin./DIORedun./MaxRankIncrease/MinHopRankIncrease/Def
. Lifetime/Lifetime Unit - controlled at root, nodes just use the value
sent by root. Implementations can easily block incorrect values.
  - OCP - configured at root and nodes. Implementations can easily block
incorrect value configs (node specific misconfig). But valid OCP per
node but incorrect network wide cannot be detected and blocked at root.
- Section 17.2.3 says every node should be configured with instance id,
ocp, and few other parameters, which implies a node should reject a DIO
if it fails to match OCP.
- Two roots including different routing metrics is a very good
considerations and a issue related to the current one being discussed. A
given OCP can have multiple metrics, for example OCP1 can have etx and
latency metrics, without this info how does a node make a decision
whether to join a DAG or not? OCP is a 16-bit field, do we really need
to further divide it based on metrics? Can't we have one OCP value per
metric?

Cheers,
Rajesh

> -----Original Message-----
> From: Philip Levis [mailto:[email-masked]]
> Sent: Tuesday, November 30, 2010 12:18 PM
> To: Rajesh Marchappanavar (rmarchap)
> Cc: Michael Richardson; [email-masked]
> Subject: Re: [Roll] Make OCP part of DIO base object or make
> DODAGconfiguration mandatory for all DIOs
> 
> 
> On Nov 29, 2010, at 10:51 AM, Rajesh Marchappanavar (rmarchap) wrote:
> >>
> >
> > [RM:] That is because OCP differentiates dags, it's not just a
> > 'configuration option'. A node can join 2 dags of different OCP,
> > instance-id, and dag-id. Which means OCP is a dag characteristic and
> not
> > just one of the configuration option. The fact that two nodes
> advertise
> > same instance-id, dag-id, and different OCP is a mis-configuration.
> They
> > should be advertising different instance-id, dag-id, and ocp. That
> said,
> > nodes need to deal with such configuration errors.
> 
> This statement is technically incorrect. An OCP does not differentiate
> DAGs. An OCP is associated with a DAG. There is a one-to-one mapping
> between OCPs and DAGs. The draft is quite clear on this. Different
OCPs
> on the same DAG is a (serious) configuration error: while it's
> important that RPL can detect this, I'd argue it's outside the scope
of
> the protocol (or any routing protocol) to proactively deal with such
> problems. The resulting complexity of dealing with all of the possible
> configuration errors is just too great.
> 
> Phil

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Wed, 8 Dec 2010 09:58:45 -0800

Should I conclude that this will not be handled at protocol level...

Cheers,
Rajesh

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Rajesh Marchappanavar (rmarchap)
> Sent: Thursday, December 02, 2010 7:08 AM
> To: Philip Levis
> Cc: [email-masked]
> Subject: Re: [Roll] Make OCP part of DIO base object or
> makeDODAGconfiguration mandatory for all DIOs
> 
> 
DIOIntDoubl./DIOIntMin./DIORedun./MaxRankIncrease/MinHopRankIncrease/De
> f
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll