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

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Wed, 24 Nov 2010 18:12:44 -0800

Hi,

Consider a setup with 2 LBRs or DAG roots configured with same
instance-id and dag-id but different ocp-type.

LBR1---------Node-------------LBR2

Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is
configured to join OCP0.

LBR1 starts up first, Node hears DIO from LBR1 and joins OCP0 dag.

LBR2 sends DIO with configuration option, Node fails to match OCP and
rejects DIO. All fine.

LBR2 sends DIO with only Base option, Node would select LBR2 as
alternate parent assuming rank and version number are same as LBR1's.

A node now has a OCP0 preferred parent and a OCP1 alternate parent.
Based on network situation, Node could be flapping between a

OCP0 dag and a OCP1 dag.

This seems to be a major issue unless somebody can help explain RPL
behavior is such cases.

You could say this is a misconfiguration, true, but how would a Node
detect and reject this misconfig?

IMO, we should either make OCP part of DIO base object or make DODAG
configuration option mandatory for DIOs.

Please share your thoughts.

Cheers,

Rajesh

---

From: Philip Levis <[email-masked]>
Date: Wed, 24 Nov 2010 18:23:35 -0800

On Nov 24, 2010, at 6:12 PM, Rajesh Marchappanavar (rmarchap) wrote:

>  
> Hi,
>  
> Consider a setup with 2 LBRs or DAG roots configured with same instance-id and dag-id but different ocp-type.
>  
> Say LBR1 is configured with OCP0 and LBR2 with OCP1 and Node is configured to join OCP0.
> LBR2 sends DIO with configuration option, Node fails to match OCP and rejects DIO. All fine.
> LBR2 sends DIO with only Base option, Node would select LBR2 as alternate parent assuming rank and version number are same as LBR1’s.
> A node now has a OCP0 preferred parent and a OCP1 alternate parent. Based on network situation, Node could be flapping between a
> OCP0 dag and a OCP1 dag.
>  
> This seems to be a major issue unless somebody can help explain RPL behavior is such cases.
> You could say this is a misconfiguration, true, but how would a Node detect and reject this misconfig?
>  
> IMO, we should either make OCP part of DIO base object or make DODAG configuration option mandatory for DIOs.

LBR1 and LBR2 use different OCPs if and only if they are part of different DODAGs. Node needs to keep track of the DODAG -> OCP mapping and act accordingly.

Phil

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Wed, 24 Nov 2010 18:33:23 -0800

> -----Original Message-----
> From: Philip Levis [mailto:[email-masked]]
> Sent: Thursday, November 25, 2010 7:54 AM
> To: Rajesh Marchappanavar (rmarchap)
> Cc: [email-masked]
> Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG
> configuration mandatory for all DIOs
> 
> 
> LBR1 and LBR2 use different OCPs if and only if they are part of
> different DODAGs. Node needs to keep track of the DODAG -> OCP mapping
> and act accordingly.

[RM:] Instance-id, DODAG-id and OCP are configurable parameters on
root/LBR, if network administrator configures same instance-id, DODAG-id
and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part of same
DODAG or different DODAG?

Cheers,
Rajesh

---

From: Philip Levis <[email-masked]>
Date: Wed, 24 Nov 2010 18:57:45 -0800

> DODAG or different DODAG?

This would be a configuration error that violates the specification.

Phil

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Wed, 24 Nov 2010 19:12:36 -0800

> Sent: Thursday, November 25, 2010 8:28 AM

[RM:] True and I already said that. How does a node handle this
configuration error? Putting ocp in DIO base object would help handle
various such issues.

Cheers,
Rajesh

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 25 Nov 2010 08:54:11 -0600 (CST)

>LBR1 and LBR2 use different OCPs if and only if they are part of different DODAGs.

Just a little correction:

LBR1 and LBR2 can use different OCPs if and only if they are part of different RPL Instances.

Here is the relevant quote from Section 3.1.2 of RPL-15:

"A RPLInstanceID identifies a set of
      one or more Destination Oriented DAGs (DODAGs).  A network may
      have multiple RPLInstanceIDs, each of which defines an independent
      set of DODAGs, which may be optimized for different Objective
      Functions (OFs) and/or applications.  The set of DODAGs identified
      by a RPLInstanceID is called a RPL Instance.  All DODAGs in the
      same RPL Instance use the same OF."

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, November 24, 2010 8:23:35 PM
Subject: Re: [Roll] Make OCP part of DIO base object or make DODAG	configuration mandatory for all DIOs

Phil
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Thu, 25 Nov 2010 10:15:59 -0800

The keyword here is "misconfiguration". Are you all suggesting RPL nodes do not/will not have capability to detect/handle misconfigs?

Cheers,
Rajesh

> From: Mukul Goyal [mailto:[email-masked]]
> Sent: Thursday, November 25, 2010 8:24 PM
> To: Philip Levis
> Cc: [email-masked]; Rajesh Marchappanavar (rmarchap)
> Subject: Re: [Roll] Make OCP part of DIO base object or make
> DODAGconfiguration mandatory for all DIOs
> 
> different DODAGs.
> alternate parent assuming rank and version number are same as LBR1’s.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Nov 2010 09:34:43 -0500

>>>>> "Rajesh" == Rajesh Marchappanavar <(rmarchap)" <[email-masked]>> writes:

    Rajesh> [RM:] True and I already said that. How does a node handle this
    Rajesh> configuration error? Putting ocp in DIO base object would
    Rajesh> help handle various such issues.

I'm not sure why moving the location of the OCP would help.

Rajesh asks a legitimate question: protocols must specify responses to
external actions, with some transitions labelled as illegal.  It's not
useful to label a possible configuration as illegal: because a network
node can only control it's own behaviour.   Instead, we must be able to 
identify transitions in the state machine as being illegal.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Mon, 29 Nov 2010 07:56:36 -0800

>     >> > root/LBR, if network administrator configures same instance-
> id,
>     >> DODAG-id
>     >> > and different OCPs on LBR1 and LBR2, are LBR1 and LBR2 part
of
> same

[RM:] Instance-id, dag-id, version number and ocp identify a dag. 
While the first 3 parameters are in DIO base object, ocp is in optional
configuration option.
This creates situations like the one I mentioned earlier. Repeating the
issue here - if there
are 2 roots configured with same instance-id/dag-id/ver-num but
different ocps, and the roots
do not always send configuration option in DIO, then on receiving a DIO
without config option, a node
would consider both the DIOs valid and has no means of knowing the 2
roots are actually hosting dags
for different ocps. This would lead the node selecting one root as
preferred parent and another as
alternate parent although the 2 roots dags are of different ocps.

If ocp is moved to DIO base object or by making configuration option
mandatory in DIO, a node would
detect the misconfig and reject DIO from second root when it is already
attached to the first ocp DAG.

Cheers,
Rajesh

> ] [email-masked] http://www.sandelman.ottawa.on.ca/
|device
> driver[
>    Kyoto Plus: watch the video
> <http://www.youtube.com/watch?v=kzx1ycLXQSE>
> 	               then sign the petition.
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Nov 2010 12:20:23 -0500

>>>>> "Rajesh" == Rajesh Marchappanavar <(rmarchap)" <[email-masked]>> writes:
    Rajesh> [RM:] Instance-id, dag-id, version number and ocp identify a dag. 
    Rajesh> While the first 3 parameters are in DIO base object, ocp is
    Rajesh> in optional 
    Rajesh> configuration option.
    Rajesh> This creates situations like the one I mentioned
    Rajesh> earlier. Repeating the 
    Rajesh> issue here - if there
    Rajesh> are 2 roots configured with same instance-id/dag-id/ver-num but
    Rajesh> different ocps, and the roots
    Rajesh> do not always send configuration option in DIO, then on
    Rajesh> receiving a DIO 

So the real bug is that the receiving node, which wants a specific DAG,
taking into account the non-default OCF, is making a mistake and
matching against a DIO which does not have that OCF payload.

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Nov 2010 09:39:51 -0800

> attached to the first ocp DAG.

The trivial answer is that a node can request a configuration object from another node (e.g., via a unicast DIS) before adding that node to its neighbor set. 

Phil

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Mon, 29 Nov 2010 09:55:48 -0800

> Sent: Monday, November 29, 2010 11:10 PM
> Cc: Michael Richardson; [email-masked]
> >>    Rajesh> [RM:] True and I already said that. How does a node
> handle
> >> this
> The trivial answer is that a node can request a configuration object
> from another node (e.g., via a unicast DIS) before adding that node to
> its neighbor set.

[RM:] Yes that was considered but the issue with that is, every time a
node receives a DIO without config option it would send out DIS, get a
DIO with config option and drop it because the OCP does not match. The
process would repeat every time root sends a DIO without config option.
Battery powered nodes would drain out. Instead, IMO ocp can be added to
DIO base object.

Cheers,
Rajesh

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Nov 2010 10:20:32 -0800

> Battery powered nodes would drain out. Instead, IMO ocp can be added to

I don't think I understand the exact problem you're describing. You seem to have an idea for a feature or protocol change, then are arguing for it from many directions, any one of which can be solved through other means.

If two nodes are advertising the same DODAGID, RPLInstance, and InstanceID, yet have different OCPs, that is a configuration error or bug (e.g., an implementation might have a memory bug that overwrote one of the above fields to create the conflict). It is actually a configuration error if *any* of the configuration option values are different, even across InstanceIDs. But we seem to be fixating on the OCP.

The question was "how do you detect this configuration error?" I presented the simple way in which a node can detect it: it validates the configuration of another node before adding it to its neighbor set. By definition, there is another node in the neighbor set. The node detecting the configuration mismatch can use this "correct" node (it might be the one with the error) to route some kind of configuration error report as part of a management layer.

Phil

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Mon, 29 Nov 2010 10:51:49 -0800

> Sent: Monday, November 29, 2010 11:51 PM
> I don't think I understand the exact problem you're describing. You

[RM:] Please read my first email, I will rewrite it below in this email.

> seem to have an idea for a feature or protocol change, then are
arguing
> for it from many directions, any one of which can be solved through
> other means.

[RM:] No there aren't many directions, just one. The solution you
described was tried out and I just presented the issues with that
solution, not another direction for the problem. If you can provide a
solution I will be the happiest person to use it instead of a protocol
change. Protocol change is the only solution I could think of and I am
not saying that is the only solution, I would listen to alternates
happily.

> 
> If two nodes are advertising the same DODAGID, RPLInstance, and
> InstanceID, yet have different OCPs, that is a configuration error or

[RM:] Yes I have repeated that in every email I have sent out. This is a
configuration error. Nodes needs to deal with it. If we can say in the
draft that such configuration errors could occur and exist in the
lifetime of a dag and will not be dealt with by the protocol, I am fine
with that too. But that statement has to be made in the draft.

> bug (e.g., an implementation might have a memory bug that overwrote
one
> of the above fields to create the conflict). It is actually a
> configuration error if *any* of the configuration option values are
> different, even across InstanceIDs. But we seem to be fixating on the
> OCP.

[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.

> 
> The question was "how do you detect this configuration error?" I
> presented the simple way in which a node can detect it: it validates
> the configuration of another node before adding it to its neighbor
set.
> By definition, there is another node in the neighbor set. The node
> detecting the configuration mismatch can use this "correct" node (it
> might be the one with the error) to route some kind of configuration
> error report as part of a management layer.

[RM:] Below is the problem repeated from first mail along with the issue
with your solution:

Your solution: Send a unicast DIS and get config option. Issue with that
-
LBR2 sends DIO with only base option
Node sends unicast DIS
LBR2 sends DIO with config option, Node fails to match OCP and rejects
DIO
LBR2 sends DIO with only base option
Node sends unicast DIS
LBR2 sends DIO with config option, Node fails to match OCP and rejects
DIO

This process could keep repeating, which is fine. But since RPL network
would have constraint nodes, if the node in this example happens to be a
battery powered node, its battery would drain. Is this process worth
when the simpler solution is to put ocp in DIO base object?

Cheers,
Rajesh

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Nov 2010 11:05:57 -0800

> when the simpler solution is to put ocp in DIO base object?

Is this an accurate summary: the problem is that a misconfiguration can lead to energy-inefficient behavior?

Phil

---

From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
Date: Mon, 29 Nov 2010 11:11:46 -0800

> Sent: Tuesday, November 30, 2010 12:36 AM
> >>> [RM:] Yes that was considered but the issue with that is, every
> time
> >> a
> >>> node receives a DIO without config option it would send out DIS,
> get
> >> a
> >>> Battery powered nodes would drain out. Instead, IMO ocp can be
> added
> >> to
> >>> DIO base object.
> >>
> Is this an accurate summary: the problem is that a misconfiguration
can
> lead to energy-inefficient behavior?

[RM:] Yes that is accurate with the solution you provided. Without that
solution, the problem is a node would have a preferred parent of one OCP
and a alternate parent of another OCP, basically a node joins 2 dags
(with configuration error) for same instance.

Cheers,
Rajesh

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Nov 2010 16:36:53 -0800

> (with configuration error) for same instance.

The same is true if there's a misconfiguration that sets DIOIntDoubl. to 0: this would lead to energy-inefficient behavior. Should the protocol protect against this case too? There's a configuration error if *any* of the configuration values differ between the two nodes. Should all of them be in the DIO?

Your logic seems to assume particular processing on a node. E.g., that 

"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? Another option is to keep state on that node around: there's no question that a seriously misconfigured network is going to work suboptimally. E.g., misconfigured routing tables can lead to loops... 

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 29 Nov 2010 23:23:29 -0600 (CST)

Rajesh,

The same can be said about the routing metrics in the Metric Container. 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.

It seems to me that dealing with configuration errors does not belong to the core spec.

Thanks
Mukul

----- Original Message -----
From: "Rajesh Marchappanavar (rmarchap)" <[email-masked]>
To: "Philip Levis" <[email-masked]>
Cc: [email-masked]
Sent: Monday, November 29, 2010 12:51:49 PM
Subject: Re: [Roll] Make OCP part of DIO base object or make	DODAGconfiguration mandatory for all DIOs

arguing

one

set.

Cheers,
Rajesh

---

From: Philip Levis <[email-masked]>
Date: Mon, 29 Nov 2010 22:47:37 -0800

> 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: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Nov 2010 15:43:34 +0100

Hi Rajesh

> and a alternate parent of another OCP, basically a node joins 2 dags
(with
> configuration error) for same instance.

For this specific sentence above, no a node cannot join 2 DODAGs for the
same instance, even when there is the OCP misconfig that you are talking
about

I think everything was said about the misconfiguration. There can be
only one OCP in an instance, and yes, global instances require a minimum
administration so that all roots are configured the same.

Bandwidth is often scarce on LLNs so we have to avoid repeating a number
of things in all messages. Thus we made the instance ID an index to
everything that comes configured with the DAG, including the OCP. 
Like Phil said, is a node does not have that info, it can always DIS it.
In case of misconfig, nodes will probably join the wrong DODAG. There
can be many sorts of misconfigs, including what's in the OCP. How could
the node decide? Rich nodes can always be equipped with some checks to
validate consistency and raise alerts. Other nodes will simply have to
live with it, and though the operation will not be as expected, DODAGs
will still form.

Cheers,

Pascal
http://www.xtranormal.com/watch/7011357/

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Rajesh Marchappanavar (rmarchap)
> Sent: Monday, November 29, 2010 8:12 PM
> To: Philip Levis
> Cc: [email-masked]
> Subject: Re: [Roll] Make OCP part of DIO base object or
> makeDODAGconfiguration mandatory for all DIOs
> 
> 
> 
> > >>> DIO with config option and drop it because the OCP does not
match.
> > >> The
> > > solution, not another direction for the problem. If you can
provide
> > > change. Protocol change is the only solution I could think of and
I
> > am
> > >> InstanceID, yet have different OCPs, that is a configuration
error
> > or
> > >
> > > [RM:] Yes I have repeated that in every email I have sent out.
This
> > is a
> > > instance-id, and dag-id. Which means OCP is a dag characteristic
and
> > not
> > > same instance-id, dag-id, and different OCP is a
mis-configuration.
> > They
> > > Your solution: Send a unicast DIS and get config option. Issue
with
> > that
> > > -
> > > LBR2 sends DIO with only base option Node sends unicast DIS
> > > LBR2 sends DIO with only base option Node sends unicast DIS
> > > would have constraint nodes, if the node in this example happens
to
> > be a
(with
> configuration error) for same instance.
> 
> Cheers,
> Rajesh
> 
> >
> > Phil