Subject: [Roll] My notes from the meeting

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 1 Oct 2009 15:15:02 +0200

Hi Tim (and all):

Please find my annotated notes on the changes that were proposed at the
interim in ROLLE:

1) Multi Topology Routing (MTR) is adopted as a base spec to handle
heterogeneous requirements
	A topology is defined by where it goes (destination, default)
and how to get there (OCP/OF, metrics)
	We need in the intro to say that topologies controlled by
ship-in-the-night instances of the protocol.
	TopoID== instanceID is indicated in all control messages, and
encoded in the flow label in all packets
	Requires provisioning when using other than the default
topology.
	Default topo is topoID 0. In general all nodes are expected to
participate at least to that one.
	Passed the intro, the text will (mostly) only need to explain to
what happens within one instance.
	Much of that is hopefully very close to the current text :)

2) Proposal to make (1 instance == 1 DAG)
	RPL requires that a DAG be rooted at one destination. The root
heartbeats the protocol, eg increases the sequence.
	Proposal is doable when there's a backbone link; one of the
roots plays the role of a virtual rank 0 over the backbone
	But some other case do not have a IPv6 link as a backbone. Eg:
multiple sinks that are GW and terminate IPv6.
	So 1 instance == 1 DAG is not compatible with the current
operation
	Actually 1 instance == n DAGs improves jump opportunities and
reduces churn by divide/conquer.

3) The sequence number becomes the way we fix loops
	The detach / reattach local recovery becomes only an option. The
hold up and down timers become also optional
	Orphans that cannot jump in another DAG have to wait for the
next sequence (stimulate one with RS)?
	Until then they need to advertise an infinite rank to poison
anyway.
	Need to write down the FSM states and transitions clearly.
	
4) need to make sure that we say that even in source route, routers
issue NA-DAO for self

5) Need to add text on loop and loop recovery
	Sibling are proven valuable. Sibling loops could be prevented
adequately by simply preventing 2 sibling hops.
	NA-DAO loops can also be blocked by RPF if we know that we
receive from inwards something we'd send inwards. 
	If a router stamps its rank in a packet and says if it is
sending up, sibling or down, detection is real easy. 
	My take here is that there's room in the flow label for this:

		Flags: 4 bits. inwards vs. outwards; from sibling or
not.
		Rank: 1 octet
		InstanceID : 1 octet

	InstanceID would set by the source of the packet or the first
router. Whether mutable TBD.
	Flags and rank are mutable, updated by each router on the way,
zeroed out for crypto operations	

6) P2P optimization not fully addressed
	Discussed the use of mcast to locate nodes at app level and
trigger the routing
	Discussed on-demand reactive protocol, source route cost vs.
routing table size.
		
I also noted that DADR appears to give great results. The memory
requirement augments with the flow (pps) and reduces with the max loop
Round Trip Time (s). It seems ideal in low latency and low throughput,
and it might fix a loop before the protocol does and prevent loss. If
the packets are delayed over the max expected loop RTT, though, the loop
goes undetected. 
I also wondered what happens when some nodes play the DADR game along
the way and some do not.

My take:
- DADR applies to a subset of cases, so it can hardly be mandatory on
all types of devices. Optional could be good if we can provide an
applicability statement.
- DADR does not work for some loops so a more brutal detection -that
does not fix but at least discards packets and triggers routing - is
still needed (like the one proposed in 5).

Cheers,

Pascal

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Fri, 2 Oct 2009 15:35:44 +0200

Hi Pascal, all,

Thanks for the notes. One thing about point 1. My understanding is that
we agreed that there was no concept of "default" DAG, or "white DAG". As
JP said RPL will define one (colored) DAG, but what the color means and
how it is used is out of scope of the spec. The proposal that RPL
defines a "default DAG" concept, and especially the need for all nodes
to belong to it, was rejected as far as I understood and should be
treated if needed in a separate document.

Was my understanding correct?

Best,
Julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Pascal Thubert (pthubert)
> Sent: jeudi 1 octobre 2009 15:15
> To: Tim Winter
> Cc: IETF ROLL
> Subject: [Roll] My notes from the meeting
> 
> Hi Tim (and all):
> 
> Please find my annotated notes on the changes that were 
> proposed at the interim in ROLLE:
> 
> 1) Multi Topology Routing (MTR) is adopted as a base spec to 
> handle heterogeneous requirements
> 	A topology is defined by where it goes (destination, 
> default) and how to get there (OCP/OF, metrics)
> 	We need in the intro to say that topologies controlled 
> by ship-in-the-night instances of the protocol.
> 	TopoID== instanceID is indicated in all control 
> messages, and encoded in the flow label in all packets
> 	Default topo is topoID 0. In general all nodes are 
> expected to participate at least to that one.
> 	Passed the intro, the text will (mostly) only need to 
> explain to what happens within one instance.
> 	RPL requires that a DAG be rooted at one destination. 
> The root heartbeats the protocol, eg increases the sequence.
> 	Proposal is doable when there's a backbone link; one of 
> the roots plays the role of a virtual rank 0 over the backbone
> 	So 1 instance == 1 DAG is not compatible with the 
> current operation
> 	Actually 1 instance == n DAGs improves jump 
> opportunities and reduces churn by divide/conquer.
> 
> 	The detach / reattach local recovery becomes only an 
> option. The hold up and down timers become also optional
> 	Orphans that cannot jump in another DAG have to wait 
> for the next sequence (stimulate one with RS)?
> 	Until then they need to advertise an infinite rank to 
> poison anyway.
> 4) need to make sure that we say that even in source route, 
> routers issue NA-DAO for self
> 
> 	Sibling are proven valuable. Sibling loops could be 
> prevented adequately by simply preventing 2 sibling hops.
> 	NA-DAO loops can also be blocked by RPF if we know that 
> we receive from inwards something we'd send inwards. 
> 	If a router stamps its rank in a packet and says if it 
> is sending up, sibling or down, detection is real easy. 
> 		Flags: 4 bits. inwards vs. outwards; from 
> sibling or not.
> 		Rank: 1 octet
> 		InstanceID : 1 octet
> 
> 	InstanceID would set by the source of the packet or the 
> first router. Whether mutable TBD.
> 	Discussed the use of mcast to locate nodes at app level 
> and trigger the routing
> I also noted that DADR appears to give great results. The 
> memory requirement augments with the flow (pps) and reduces 
> with the max loop Round Trip Time (s). It seems ideal in low 
> latency and low throughput, and it might fix a loop before 
> the protocol does and prevent loss. If the packets are 
> delayed over the max expected loop RTT, though, the loop goes 
> undetected. 
> I also wondered what happens when some nodes play the DADR 
> game along the way and some do not.
> 
> My take:
> - DADR applies to a subset of cases, so it can hardly be 
> mandatory on all types of devices. Optional could be good if 
> we can provide an applicability statement.
> - DADR does not work for some loops so a more brutal 
> detection -that does not fix but at least discards packets 
> and triggers routing - is still needed (like the one proposed in 5).
> 
> Cheers,
> 
> 
> Pascal
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 2 Oct 2009 16:10:34 +0200

Hi Julien,

> Was my understanding correct?

Yes absolutely. In fact what defines the color of the DAG is the OCP.
The decision to join one of multiple DAG (instance of RPL) is a local  
policy decision of the node.
A separate ID will define the tagging mechanism used to identify to  
which DAG the packet belongs
to, similarly to MTR.

Cheers.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Oct 2009 16:35:56 +0200

Hi Julien and JP

>which DAG the packet belongs

Well, there is such a concept though it does not meet the eye.

Our spec must be self contained and the other specs are extensions. We
need to specify the field where the instanceID will appear. Otherwise
the instance extensions would not be compatible. And we need to specify
a value to put in that field. RPL will work with a zero as the default.

At that point we need to think about what happens to a router that has
RPL but no extension. If we do not say anything, such a router mixed
with a router that support instanceID will loop. So there must be a
minimum support in the base spec about instance. That minimum must
handle the case where a packet comes in with a color as well as the
operation for processing RPL packets for colored DAG.

If the minimum support is instance zero, a node that implements only the
RPL base MUST ignore RPL PDUs for non zero instances. As JP says that's
an OCP behavior, and we'll have to add an instance filter to OCP0. That
also means that when processing a packet of any color, this node will
forward it against the instance 0. To avoid loops, the default node must
thus zero out the tag.
	
That makes instance 0 the default topology... QED ;) 

Pascal

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 5 Oct 2009 11:58:06 +0200

Hi Pascal, all,

See inline.

> From: Pascal Thubert (pthubert) 
> Sent: vendredi 2 octobre 2009 16:36
> To: JP Vasseur (jvasseur); Julien Abeille (jabeille)
> Cc: Tim Winter; IETF ROLL
> Subject: RE: [Roll] My notes from the meeting
> 
> Hi Julien and JP
> 
> >> Thanks for the notes. One thing about point 1. My understanding is 
> >> that we agreed that there was no concept of "default" DAG, 
> or "white 
> >> DAG". As JP said RPL will define one (colored) DAG, but what the 
> >> color means and how it is used is out of scope of the spec. The 
> >> proposal that RPL defines a "default DAG" concept, and 
> especially the 
> >> need for all nodes to belong to it, was rejected as far as I 
> >> understood and should be treated if needed in a separate document.
> >>
> >which DAG the packet belongs to, similarly to MTR.
> 
> Our spec must be self contained and the other specs are 
> extensions. We need to specify the field where the instanceID 
> will appear. Otherwise the instance extensions would not be 
> compatible. 
[Julien] 100% Agreed

> And we need to specify a value to put in that 
> field. RPL will work with a zero as the default.
[Julien] not clear to me if this is needed, e.g. IPv6 RFC2460 defines a
Hop Limit field, but does not define any value. Other specs (e.g. ND
RFC4861) define values for specific messages.
What does a default value concept add here?
> 
> At that point we need to think about what happens to a router 
> that has RPL but no extension. If we do not say anything, 
> such a router mixed with a router that support instanceID 
> will loop. 
[Julien] the router that supports just RPL will keep packets in the same
DAG, will not use simblings. Hence there will be no loop.
> So there must be a minimum support in the base 
> spec about instance. That minimum must handle the case where 
> a packet comes in with a color as well as the operation for 
> processing RPL packets for colored DAG.
> 
[Julien] Every DAG is colored as agreed in the meeting. "0", "white", or
"default" is a color, with no different meaning than "1", "blue" as
agreed in the meeting.
> If the minimum support is instance zero,
[Julien] we did not say that there was support for only one instance ID,
because we did not give a specific meaning to 0. Hence a RPL only router
will know how to forward along the same DAG.
> a node that 
> implements only the RPL base MUST ignore RPL PDUs for non 
> zero instances. As JP says that's an OCP behavior, and we'll 
> have to add an instance filter to OCP0. That also means that 
> when processing a packet of any color, this node will forward 
> it against the instance 0. To avoid loops, the default node 
> must thus zero out the tag.
> 	
[Julien] looks like a loop ;-): 0 is the default, hence RPL only routers
do not support something else than 0, hence every router must support 0.
We do not have this issue if we do not define a "default" concept, or at
least if we define a default value, that has no semantic difference with
other values.

I feel we should move forward based on what was agreed, and avoid
redicussing points that were agreed on. The importance of defining in
RPL a white DAG that is semanticaly different from the colored ones was
not agreed in the meeting. There was a strong consensus that there will
be colors, but each with the same importance (no special meaning for
some values), and that it was admin's responsibility to configure it
properly if required. I think we should stick to this. 

Best,
Julien
 
> >>> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> >>> Of Pascal Thubert (pthubert)

---

From: JP Vasseur <[email-masked]>
Date: Mon, 5 Oct 2009 13:50:56 +0200

[snip]

>> [snip]

> properly if required. I think we should stick to this.

Yes, to make it even more simple. White is a color. If one wants to  
define white as being
unconstrained, then fine. Falling back to different colored DAG is a  
matter of local policy
although we may want to define mechanisms later on to make sure that  
packets do not
move back and forth.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 5 Oct 2009 13:53:04 +0200

[snip]

Cheers.

JP.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Oct 2009 15:50:14 +0200

Hi Julien:

Seems something was lost en-route. I try again. 

>[Julien] not clear to me if this is needed, 

If what you have is mind is to allow an RPL-base deployment to use a
non-zero value, I'm all with you.

The need for a default value comes from the "autonomicity" requirement,
IOW the capability to work with zero or minimum configuration. We cannot
force some administration on every node just to specify which color it
would operate in any given deployment, can we? So you configure nothing,
you get instance 0.

Would you agree if the terms are to default the instance field to zero
in the absence of administrative override? 
Note that this is very different from making it reserved and thus forced
to zero.

>[Julien] the router that supports just RPL will keep packets in the
same DAG, ...

A RPL-base node will do what it can with the means in the base spec and
its own policies. 

I think that the base spec must at least specify where the color is in
the packet, and that a router that forwards a packet along a given DAG
must make sure that the color in the packet matches the color of that
DAG. 

>[Julien] ... , will not use simblings. Hence

Hum... If such words exist in the spec that must be fixed. Certainly the
current spec enables siblings and that's quite unrelated with multiple
instances.

Cheers - and many thanks for the ride to the station after the interim
:)

Pascal

>From: Julien Abeille (jabeille)
>Sent: lundi 5 octobre 2009 11:58
>To: Pascal Thubert (pthubert); JP Vasseur (jvasseur)
>Cc: 'Tim Winter'; 'IETF ROLL'
Hop Limit field, but does not define
>any value. Other specs (e.g. ND RFC4861) define values for specific
messages.
>[Julien] the router that supports just RPL will keep packets in the
same DAG, will not use simblings. Hence
>there will be no loop.
>[Julien] Every DAG is colored as agreed in the meeting. "0", "white",
or "default" is a color, with no
>different meaning than "1", "blue" as agreed in the meeting.
>[Julien] we did not say that there was support for only one instance
ID, because we did not give a specific
>meaning to 0. Hence a RPL only router will know how to forward along
the same DAG.
>[Julien] looks like a loop ;-): 0 is the default, hence RPL only
routers do not support something else than 0,
>hence every router must support 0. We do not have this issue if we do
not define a "default" concept, or at
>least if we define a default value, that has no semantic difference
with other values.
>I feel we should move forward based on what was agreed, and avoid
redicussing points that were agreed on. The
>importance of defining in RPL a white DAG that is semanticaly different
from the colored ones was not agreed
>in the meeting. There was a strong consensus that there will be colors,
but each with the same importance (no
>special meaning for some values), and that it was admin's
responsibility to configure it properly if required.
>I think we should stick to this.
>
>Best,
>Julien
>>
>
>> Pascal
>> >
>> >>