Subject: [Roll] #16

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Dec 2009 11:21:21 +0100

Hi Mathilde

Issue 16 says "Hi All, This is my current understanding: - Parents are
removed based on OF selection (decision to move within the DAG, change
DAG, etc) - Destination prefixes are removed after the retry /
RemoveTimer? procedure described in section 5.10.1.1.1. This is
essentially a keep alive mechanism based on DIO (D bit set) - DAO
exchanges. - Route corresponding to destination prefixes are removed
when DAO lifetime expires? Are they also removed when the corresponding
destination prefix is removed? - When are routes corresponding to
parents removed? Do they also have a lifetime? - What happens when a
neighbor disappears, are the corresponding parents/destination/routes
removed? The current behavior seems quite asymmetric... There is some
kind of keep alive mechanism for destination prefixes, but not for
parents. There is a lifetime associated with routes corresponding to
destination prefixes but not for routes corresponding to parents. Is
that a design choice? I would appreciate some clarifications. "

Proposed new text :

   If Neighbor Unreachability Detection (NUD), or an equivalent

   mechanism, determines that a neighbor is no longer reachable, then a

   RPL node MUST NOT consider this node in the neighbor set when

   calculating and advertising routes until the node determines it is

   reachable again.

   Routes via that neighbor MUST be eliminated from the routing table,

   and the node SHOULD poison using no-DAO all DAO routes that it

   has advertised via DAO and that it can reach only via that neighbor.

The internals (keeping info about the DAOs to resync more quickly) are
not described, long as the node behaves as if it has cleaned everything
reachable only via the lost neighbor.

We'll be working on solidifying the D-bit and the DAO for ticket #17,
making it more reliable. But that cannot be done in the time frame for
rel 5.

Would the text above satisfy you for the time being?

 

Pascal Thubert
IP Engineering TC

[email-masked] <mailto:[email-masked]> 
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco Systems
  Village d'Entreprises Green Side bat. T3 
  400, Avenue Roumanille
  06410 Biot - Sophia Antipolis  
  France
  www.cisco.com/global/FR/ <http://www.cisco.com/global/FR/> 

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 4 Dec 2009 14:59:29 +0100

Hi Pascal,
 
Thanks for the update. Please see my questions below.
Best,
Mathilde

  _____  

Issue 16 says "Hi All, This is my current understanding: - Parents are
removed based on OF selection (decision to move within the DAG, change DAG,
etc) - Destination prefixes are removed after the retry / RemoveTimer?
procedure described in section 5.10.1.1.1. This is essentially a keep alive
mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to
destination prefixes are removed when DAO lifetime expires? Are they also
removed when the corresponding destination prefix is removed? - When are
routes corresponding to parents removed? Do they also have a lifetime? -
What happens when a neighbor disappears, are the corresponding
parents/destination/routes removed? The current behavior seems quite
asymmetric... There is some kind of keep alive mechanism for destination
prefixes, but not for parents. There is a lifetime associated with routes
corresponding to destination prefixes but not for routes corresponding to
parents. Is that a design choice? I would appreciate some clarifications. "

Proposed new text :

   reachable again.  

The internals (keeping info about the DAOs to resync more quickly) are not
described, long as the node behaves as if it has cleaned everything
reachable only via the lost neighbor.

>> Does this mean that there is no lifetime associated with DAO routes?

>> Is the retry_count + RemoveTimer procedure maintained in version 05? 

>> Does this mean that the local confidence is the only criteria to assess
neighbor (including parents and child) reachability?

Best,

Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Dec 2009 15:19:12 +0100

>> Does this mean that there is no lifetime associated with DAO routes?

There is no lifetime per se. The routes are periodically checked using the D bit in DIO.

>>Is the retry_count + RemoveTimer procedure maintained in version 05? 

The retry count and remove timers are maintained. The unconfirmed entries are inconsistencies that cause additional trickled DIO that act as retries.

>> Does this mean that the local confidence is the only criteria to assess neighbor (including parents and child) reachability?

Yes. 

What we have today:

If an interface goes down all neighbors across that interface go down. If the confidence mechanism declares that a neighbor is no more reachable, the neighbor goes down.

If a neighbor goes down all adjacencies via that neighbors are removed. This boils down to all routes that are only via that neighbor go away, while a same route with a higher cost via an alternate neighbor might pop up.

If a DAO entry was not refreshed after retry count then the entry and the associated adjacency are clean up. The remove timer allows a small jitter to avoid no-DAO collisions.

All this is pretty classical.

What we do not have today (I understand that's your question) is something like if we lose all the DAO entries via a given neighbor from the retry count then we would declare that the neighbor is down. We do not have such inference.

Would you need more?

Pascal

From: Mathilde Durvy (mdurvy) 
Sent: vendredi 4 décembre 2009 14:59
To: Pascal Thubert (pthubert)
Cc: [email-masked]'
Subject: RE: #16

Hi Pascal,

Best,

Mathilde

________________________________

Issue 16 says "Hi All, This is my current understanding: - Parents are removed based on OF selection (decision to move within the DAG, change DAG, etc) - Destination prefixes are removed after the retry / RemoveTimer? procedure described in section 5.10.1.1.1. This is essentially a keep alive mechanism based on DIO (D bit set) - DAO exchanges. - Route corresponding to destination prefixes are removed when DAO lifetime expires? Are they also removed when the corresponding destination prefix is removed? - When are routes corresponding to parents removed? Do they also have a lifetime? - What happens when a neighbor disappears, are the corresponding parents/destination/routes removed? The current behavior seems quite asymmetric... There is some kind of keep alive mechanism for destination prefixes, but not for parents. There is a lifetime associated with routes corresponding to destination prefixes but not for routes corresponding to parents. Is that a design choice? I would appreciate some clarifications. "

Proposed new text :

   reachable again.  

The internals (keeping info about the DAOs to resync more quickly) are not described, long as the node behaves as if it has cleaned everything reachable only via the lost neighbor.

>> Does this mean that the local confidence is the only criteria to assess neighbor (including parents and child) reachability?

Best,

Mathilde

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 4 Dec 2009 16:39:13 +0100

Hi Pascal,

>> Does this mean that there is no lifetime associated with DAO routes?

There is no lifetime per se. The routes are periodically checked using the D
bit in DIO.

[Mathilde] So if I understand correctly the DAO lifetime is removed for the
DAO packet

>>Is the retry_count + RemoveTimer procedure maintained in version 05? 

The retry count and remove timers are maintained. The unconfirmed entries
are inconsistencies that cause additional trickled DIO that act as retries.

Yes. 

[Mathilde] I guess my point is that I see a small contradiction in your
answers to the 2 previous questions. If we use only local confidence to
assess neighbor reachability why do we need an extra mechanism to assess the
reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test reachability to a neighbor,
the local confidence tests the reachability to the same neighbor, why do we
use both?

Is it that the local confidence is too 'slow' for DAO neighbors (children)
but good enough for DIO neighbors (parents)?

I would just like to understand the reasoning, otherwise I'm happy with the
change you propose.

What we have today ...

 [Mathilde] Agree 

Best,

Mathilde

Hi Pascal,

Best,

Mathilde

  _____  

Issue 16 says “Hi All, This is my current understanding: - Parents are
parents. Is that a design choice? I would appreciate some clarifications. ”

Proposed new text :

   reachable again.  

Best,

Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Dec 2009 17:14:12 +0100

Hi Mathilde:

 [Mathilde] So if I understand correctly the DAO lifetime is removed for the DAO packet

The DAO lifetime is the lifetime of the prefix, not that of the route. You can hardly say how long a route can be valid.

After that lifetime expires, the prefix will not exist anymore so obviously, if the lifetime was not refreshed,  the route associated has to be removed.

[Mathilde] I guess my point is that I see a small contradiction in your answers to the 2 previous questions. If we useonly local confidence to assess neighbor reachability why do we need an extra mechanism to assess the reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test reachability to a neighbor, the local confidence tests the reachability to the same neighbor, why do weuse both?

Is it that the local confidence is too 'slow' for DAO neighbors (children) but good enough for DIO neighbors (parents)?

I would just like to understand the reasoning, otherwise I'm happy with the change you propose.

The local confidence assesses reachability of the neighbor.

A neighbor might be lost if

-          NUD declares it unreachable

-          The link goes down

The retry_count + RemoveTimer test assesses reachability of the final destination, may far behind the neighbor

A final destination might be lost for a number of reasons if you look at it

-          No DAO (null lifetime)

-          Prefix Lifetime expires

-          Retry count expires

-          Last neighbor via which we have a route to destination goes down

-          Routing shutdown

-          ...

 Makes sense?

Pascal

Hi Pascal,

Best,

Mathilde

Proposed new text :

   reachable again.  

Best,

Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Dec 2009 17:22:20 +0100

BTW Mathilde, 

1)      You right, the periods are decoupled. And it's unclear to me that all nodes would always send DAOs.

2)      You can use the fact that the neighbors answers to the DIO with a DAO as a upper layer reachability confirmation

3)      We'll propose to make the ack more explicit in 6 with a DAO trigger sequence that ensures that the D bit is not lost

Cheers,

Pascal

From: Mathilde Durvy (mdurvy) 
Sent: vendredi 4 décembre 2009 16:39
To: Pascal Thubert (pthubert)
Cc: [email-masked]'
Subject: RE: #16

Hi Pascal,

Yes. 

What we have today ...

 [Mathilde] Agree 

Best,

Mathilde

Hi Pascal,

Best,

Mathilde

Proposed new text :

   reachable again.  

Best,

Mathilde

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 7 Dec 2009 15:42:12 +0100

Hi Pascal,
 
I agree with NUD or others being used for neighbor reachability (different from e.g. parent reachability and applies to all RPL "peers")
. 
what is the difference between the lifetime of a prefix and the lifetime of a route?
we still have two mechanisms here to decide whether a route is still valid (if i get it right):
- DIO with D bit
- lifetime
why?
Best,
Julien

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
	Sent: vendredi 4 décembre 2009 17:14
	To: Mathilde Durvy (mdurvy)
	Cc: [email-masked]
	Subject: Re: [Roll] #16

	Hi Mathilde:

	 

	-          The link goes down

	-          No DAO (null lifetime)

	-          Retry count expires

	-          Routing shutdown

	-          ...

	 Makes sense?

	Pascal

	Hi Pascal,

	Best,

	Mathilde

	 

	Proposed new text :

	   reachable again.  

	Best,

	Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Dec 2009 16:56:59 +0100

Hi Julien:

There is no such thing as a lifetime of a route. The routing protocol maintain the routes for as long as they can be they cannot predict how long that will be.

A prefix, a registration, a router and an address all have a lifetime with IPv6 because administratively, there's some process to lock resourced, and then renew or renumber.

This is what the prefix lifetime in DAO is about. A capping of how long things are administratively expected to be there. So that a peer does not keep associated resources a lot longer than the parent resource it depends on.

Cheers,

Pascal

From: Julien Abeille (jabeille) 
Sent: lundi 7 décembre 2009 15:42
To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc: [email-masked]
Subject: RE: [Roll] #16

Hi Pascal,

. 

- DIO with D bit

- lifetime

why?

Best,

Julien

	Hi Mathilde:

	 

	-          The link goes down

	-          No DAO (null lifetime)

	-          Retry count expires

	-          Routing shutdown

	-          ...

	 Makes sense?

	Pascal

	Hi Pascal,

	Best,

	Mathilde

	 

	Proposed new text :

	   reachable again.  

	Best,

	Mathilde

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 7 Dec 2009 17:01:25 +0100

Hi Pascal,
 
I get it, I think we just disagreed on terms. I'll still call it a route lifetime ;-) (even though it is an admin concept, decoupling totally the admin from the actual route does not help as the forwarding engine will use the route even if it is supposedly just administratively up).
 
Best,
Julien

	From: Pascal Thubert (pthubert) 
	Sent: lundi 7 décembre 2009 16:57
	To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy)
	Cc: [email-masked]'
	Subject: RE: [Roll] #16

	Hi Julien:

	Cheers,

	Pascal

	Hi Pascal,

	. 

	- DIO with D bit

	- lifetime

	why?

	Best,

	Julien

		Hi Mathilde:

		 

		-          The link goes down

		-          No DAO (null lifetime)

		-          Retry count expires

		-          Routing shutdown

		-          ...

		 Makes sense?

		Pascal

		Hi Pascal,

		Best,

		Mathilde

		 

		Proposed new text :

		   reachable again.  

		Best,

		Mathilde

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Dec 2009 17:14:55 +0100

Julien, Mathilde:

Would this change help?

                 time the packet is sent) that the Destination Prefix is valid

-                for route determination. A value of all one bits (0xFFFFFFFF)

-                represents infinity. A value of all zero bits (0x00000000)

-                indicates a loss of reachability.

+                for route determination.

+               The lifetime is initially set by the node that owns the prefix

+               and denotes the valid lifetime for that prefix (aka AdvValidLifetime).

+

+               The value might be reduced by the originator and/or en-route nodes

+               that would not provide connectivity for the whole valid lifetime.

+                                                             

+               A value of all one bits (0xFFFFFFFF) represents infinity. 

+               A value of all zero bits (0x00000000) indicates a loss of 

+               reachability.

And yes, that value caps the time a node should maintain a route learnt from DAO though the default for AdvValidLifetime is a month...

Pascal

From: Julien Abeille (jabeille) 
Sent: lundi 7 décembre 2009 17:01
To: Pascal Thubert (pthubert); Mathilde Durvy (mdurvy)
Cc: [email-masked]'
Subject: RE: [Roll] #16

Hi Pascal,

Best,

Julien

	Hi Julien:

	Cheers,

	Pascal

	Hi Pascal,

	. 

	- DIO with D bit

	- lifetime

	why?

	Best,

	Julien

		Hi Mathilde:

		 

		-          The link goes down

		-          No DAO (null lifetime)

		-          Retry count expires

		-          Routing shutdown

		-          ...

		 Makes sense?

		Pascal

		Hi Pascal,

		Best,

		Mathilde

		 

		Proposed new text :

		   reachable again.  

		Best,

		Mathilde

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 7 Dec 2009 17:17:02 +0100

Hi Pascal,
 
this works for me.
Julien

	From: Pascal Thubert (pthubert) 
	Sent: lundi 7 décembre 2009 17:15
	To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy)
	Cc: [email-masked]'
	Subject: RE: [Roll] #16

	Julien, Mathilde:

	Would this change help?

	+

	+                                                             

	+               reachability.

	Pascal

	Hi Pascal,

	Best,

	Julien

		Hi Julien:

		Cheers,

		Pascal

		Hi Pascal,

		. 

		- DIO with D bit

		- lifetime

		why?

		Best,

		Julien

			Hi Mathilde:

			 

			-          The link goes down

			-          No DAO (null lifetime)

			-          Retry count expires

			-          Routing shutdown

			-          ...

			 Makes sense?

			Pascal

			Hi Pascal,

			Best,

			Mathilde

			 

			Proposed new text :

			   reachable again.  

			Best,

			Mathilde

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 7 Dec 2009 17:22:00 +0100

OK for me too!
Best,
Mathilde

  _____  

From: Pascal Thubert (pthubert) 
Sent: lundi, 7. décembre 2009 17:15
To: Julien Abeille (jabeille); Mathilde Durvy (mdurvy)
Cc: [email-masked]'
Subject: RE: [Roll] #16

Julien, Mathilde:

Would this change help?

                 time the packet is sent) that the Destination Prefix is
valid

-                for route determination. A value of all one bits
(0xFFFFFFFF)

+               The lifetime is initially set by the node that owns the
prefix

+               and denotes the valid lifetime for that prefix (aka
AdvValidLifetime).

+

+               The value might be reduced by the originator and/or en-route
nodes

+               that would not provide connectivity for the whole valid
lifetime.

+                                                             

+               reachability.

And yes, that value caps the time a node should maintain a route learnt from
DAO though the default for AdvValidLifetime is a month…

Pascal

Hi Pascal,

I get it, I think we just disagreed on terms. I'll still call it a route
lifetime ;-) (even though it is an admin concept, decoupling totally the
admin from the actual route does not help as the forwarding engine will use
the route even if it is supposedly just administratively up).

Best,

Julien

  _____  

Hi Julien:

There is no such thing as a lifetime of a route. The routing protocol
maintain the routes for as long as they can be they cannot predict how long
that will be.

A prefix, a registration, a router and an address all have a lifetime with
IPv6 because administratively, there’s some process to lock resourced, and
then renew or renumber.

This is what the prefix lifetime in DAO is about. A capping of how long
things are administratively expected to be there. So that a peer does not
keep associated resources a lot longer than the parent resource it depends
on.

Cheers,

Pascal

Hi Pascal,

I agree with NUD or others being used for neighbor reachability (different
from e.g. parent reachability and applies to all RPL "peers")

. 

what is the difference between the lifetime of a prefix and the lifetime of
a route?

we still have two mechanisms here to decide whether a route is still valid
(if i get it right):

- DIO with D bit

- lifetime

why?

Best,

Julien

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pascal Thubert (pthubert)
Sent: vendredi 4 décembre 2009 17:14
To: Mathilde Durvy (mdurvy)
Cc: [email-masked]
Subject: Re: [Roll] #16

Hi Mathilde:

The DAO lifetime is the lifetime of the prefix, not that of the route. You
can hardly say how long a route can be valid.

After that lifetime expires, the prefix will not exist anymore so obviously,
if the lifetime was not refreshed,  the route associated has to be removed.

[Mathilde] I guess my point is that I see a small contradiction in your
answers to the 2 previous questions. If we useonly local confidence to
assess neighbor reachability why do we need an extra mechanism to assess the
reachability to the neighbors that are sending DAOs to us?

In other word the retry_count + RemoveTimer test reachability to a neighbor,
the local confidence tests the reachability to the same neighbor, why do
weuse both?

-          The link goes down

The retry_count + RemoveTimer test assesses reachability of the final
destination, may far behind the neighbor

-          No DAO (null lifetime)

-          Retry count expires

-          Routing shutdown

-          …

 Makes sense?

Pascal

Hi Pascal,

Best,

Mathilde

  _____  

Proposed new text :

   reachable again.  

Best,

Mathilde