Subject: [Roll] Question for the WG

From: JP Vasseur <[email-masked]>
Date: Thu, 29 Oct 2009 18:05:45 +0100

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

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 30 Oct 2009 09:00:23 +0100

Hi JP,

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur (jvasseur)
	Sent: jeudi 29 octobre 2009 18:06
	To: roll ROLL
	Subject: [Roll] Question for the WG

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

	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.

	[Julien] I am in favor of 2. It's a matter of configuring the
root properly, which is not that muc an effort I feel. Most people will
want to deploy using a specific metric, hence OCP0 means:
	-  the network admin failed to configure the network properly
	- this is extra code on the sensors, that will be rarely used

	     A
	   /   \
	 B    C

	    X

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

	1) Option 1

	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 

	I personally favor 2). 
	[Julien] question about 2: I guess the parent chosen by X will
not be able to advertise anything specific to X (X does not send DAOs),
except if X configures an address on a prefix routed to B/C. Hence would
a good way to provide what you propose simply that X and his parent do
an RS/RA exchange, RA with a prefix information option, autoconf flag
set, on link flag probably not set, and router lifetime != 0. This would
ensure X has a default route and X has an address forged on a prefix
that his parent is advertising in DAOs up the DAG (in other terms X
address is routable). If this works I am for 2.

	Opinions ?

	Thanks.

	JP.

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 30 Oct 2009 10:28:30 -0400

From: JP Vasseur <[email-masked]>
   Date: Thu, 29 Oct 2009 18:05:45 +0100

I prefer option 2.  Option 1 is more complicated, as there
has to be a way to specify a non-default OCP, and I have no
conviction that a majority of DAGs will use the default OCP.

If the goal is to have a smaller base DIO, then we should
put the OCP in a DIO option to be included in all DIOs sent
in response to solicitations (DIS).  A joining device can
request a DAO in order to get the OCP, but OCPs would not be
included in the majority of DIOs.  This is about as complex
as option 1 and saves bandwidth even when using non-default
OCPs.

I would still prefer option 2 over this.  I am not convinced
that the gain in bandwidth would be worth the added
complexity of dealing with another option.

       A
      / \
     B   C

       X

   1) Option 1

   2) Option 2

   3) Option 3

I prefer Option 2.  Option 3 would make for a lot of
interoperation headaches without providing much in
return.

Option 1 is available whether RPL explicitly supports
it or not.  We can't force devices to participate in
a network.
                           -Richard Kelsey

---

From: [email-masked]
Date: Fri, 30 Oct 2009 14:57:40 -0500

JP,

I guess I would defer my position on Question 2 below until we decide the 
converse issue.  That is, if a node receives a data packet from another 
node in the LLN whose OCP it does not support, what should the receiving 
node do with the packet?  If we decide that the packet be dropped, then I 
would select Question 2/Option 1. (No reason to join the DAG if it can't 
pass messages on the DAG).    If however, we decide the packet should be 
sent along its merry way toward its destination even on an OCP mismatch, 
then we might be damaging the DAG's integrity. 

I think the best approach at the onset is being very explicit.  As we gain 
experience and implementations are tested, we can add additional nuances 
into the protocol.  Hence, my vote for Question 1 is if a node wanting to 
join the DAG cannot find at least one neighbor supporting its OCP, then it 
does not join the DAG. 

As for Question 2, I vote for always explicitly naming the OCP/metric.  If 
we allow a 'default' metric that means that every node must constantly 
maintain a completely parallel set of parents, preferred parents, DAO 
states etc for the 'default' OCP even though it may never need to use the 
default OCP.

Jerry

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
10/29/2009 12:05 PM

To
roll ROLL <[email-masked]>
cc

Subject
[Roll] Question for the WG

(chair hat off)

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

     A
   /   \
 B    C

    X

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

1) Option 1

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 

I personally favor 2).

Opinions ?

Thanks.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 31 Oct 2009 13:59:17 +0100

Hi Jerry

I guess I would defer my position on Question 2 below until we decide
the converse issue.  That is, if a node receives a data packet from
another node in the LLN whose OCP it does not support, what should the
receiving node do with the packet?  If we decide that the packet be
dropped, then I would select Question 2/Option 1. (No reason to join the
DAG if it can't pass messages on the DAG).    If however, we decide the
packet should be sent along its merry way toward its destination even on
an OCP mismatch, then we might be damaging the DAG's integrity.   

You're right. And the current text does not allow a packet to go its
merry way because that would cause a loop. It leaves to policy which
instances the node belongs to, and whether the instance ID  in the
packet can be changed. By default that is not done, unless the node
participates to instance ID 0 in which case, yes.

What's behind this is the need for autonomic behavior. What happens to a
device - or a full network of devices - straight out of the box?

If some McDo toys start RPLing together, do we need to ask the kids to
configure policies and instances to get them to work?

So the current text enables such operation using OCP/OF 0. That's
basically what you get for hosts and routers that do not know any
better, that is have no configuration at all. Whether an administered
deployment should use OCP0 at all is an network planning issue.

 "5.11.2.  Instance Forwarding

   Instance IDs is used to avoid loops between DAGs from different
   origins.  DAGs that constructed for antagonistic constraints might
   contain paths that, if mixed together, would yield loops.  Those
   loops are avoided by forwarding a packet along the DAG that is
   associated to a given instance.
 
   The InstanceID is placed by the source in the flow label.  It is not
   meaningful if the packet has the flow label set to all zeroes.
   Otherwise it MUST match the DAG instance onto which the packet is
   placed by any node, be it a host or router.
 
   When a router receives a packet that is flagged with a given instance
   ID and the node can forward the packet along the DAG associated to
   that instance, then the router MUST do so and leave the instance ID
   flag unchanged.
 
   If any node can not forward a packet along the DAG associated to the
   instance ID in the flow label, then the node MAY either change the
   InstanceID to match a DAG that it is using for this packet or discard
   the packet.  That decision is based on a policy.
 
   The default policy is as follows: if the node can forward along the
   DAG associated to the instance RPL_DEFAULT_INSTANCE then it should do
   so.  Otherwise it should drop the packet.

"

I think the best approach at the onset is being very explicit.  As we
gain experience and implementations are tested, we can add additional
nuances into the protocol.  Hence, my vote for Question 1 is if a node
wanting to join the DAG cannot find at least one neighbor supporting its
OCP, then it does not join the DAG.   

The way I understand the question that JP asks is not along this line. I
think the question is whether a network that is a patchwork of instances
makes any sense. The abstract rank metric enables loop avoidance in such
a network, but the Objective is not guaranteed anymore and the metrics
are not propagated.

For me, since a node should always join along known instances first, the
instance DAGs are not changed by that decision. The difference is only
whether you can have stubs of OCP 0 hanging off the DAG or nodes left
with no connectivity at all. I tend to allow to give connectivity to the
poor chaps, but I suppose that in any controlled environment that does
not make a difference.

As for Question 2, I vote for always explicitly naming the OCP/metric.
If we allow a 'default' metric that means that every node must
constantly maintain a completely parallel set of parents, preferred
parents, DAO states etc for the 'default' OCP even though it may never
need to use the default OCP. 

I think you have reversed the order of the questions J There is no must
use instance 0. It is just a default when nothing is configured that can
be used or not when things are configured. The question seems to be
whether OCP should be in the base DIO as opposed to an option. I do not
mind have a strong opinion on that since the current text only means to
compress 0. It's just an optimization...

Jerry 

10/29/2009 12:05 PM 

To

cc

Subject

		

(chair hat off) 

We had that text is -03: 

     A 
   /   \ 
 B    C 

    X 

1) Option 1 

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 

I personally favor 2). 

Opinions ? 

Thanks.