Subject: [Roll] Closing issue #58: Clarification on DAO

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Jul 2010 18:42:21 +0200

Dear WG

I think we can close 58. 11 will have the following changes:

>  - “Multicast DAOs MUST NOT include Transit Information options” (Section
> 8.6). Do you mean “MUST not include a parent address in the transit
> information option”?

Corrected along the proposal

>  - Section 16.2.6 (which deals with configuration) introduces some  terminology
> not used in the spec (e.g UNREACHABLE state). Is this some  legacy text?

Legacy text removed.

>  - What actions need to be taken by a node that didn’t get a DAO-ACK  response
> when setting the K bit?

The text leaves that to implementation. Should not retry indefinitely though!

If anybody opposes to close along the above line please speak up : )

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of roll
> issue tracker
> Sent: Tuesday, July 13, 2010 11:14 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Roll] [roll] #58: Clarification on DAO
> 
> #58: Clarification on DAO
> -----------------------------+------------------------------------------
> -----------------------------+----
>  Reporter:  jpv@…            |       Owner:
>      Type:  enhancement      |      Status:  new
>  Priority:  major            |   Milestone:
> Component:  rpl              |     Version:
>  Severity:  In WG Last Call  |    Keywords:
> -----------------------------+------------------------------------------
> -----------------------------+----
>  Hello Mathilde
> 
>  - What is the DAO parent selection criteria for OCP0? Same as for DIO  parents
> I assume.
>  [Pascal] OF0 only mandates one preferred parent with good enough
> bidirectional connectivity, and it enables a backup if one is available.
>  So yes, there’s little choice but pick it as DAO parent as well. The draft  could
> have an additional sentence to say that I admit.
> 
>  - What actions need to be taken by a node that didn’t get a DAO-ACK  response
> when setting the K bit?
>  [Pascal] We have to refine that text in 11 for sure. Only new information  is
> sent asynchronously to the DAO parents while the full information is  sent in
> demand (upon DTSN or new version). In short, the rich  implementation can
> maintain per parent what was acknowledged and flag it  as not new. The
> constrained implementation sends the delta once and flag  it as not new
> without an ack, waiting for the next full information to  fill the gaps. So
> basically when something new is learnt, the storing  router arms a timer to
> schedule a DAO. When the timer elapses, the router  sends all new information
> to the parents. The timer keeps elapsing for a  given parent till the parent acks
> the most recent DAO sequence sent to it  or the router gives up. If the router
> gives up, the parent is out of sync  till the next change or full information
> updates it. The path sequence  that circulates via other parents that are not out
> of sync is fresher and  enables the ancestors to select the usable path.
> 
>  - Section 16.2.6 (which deals with configuration) introduces some  terminology
> not used in the spec (e.g UNREACHABLE state). Is this some  legacy text?
>  [Pascal] It is. That state was in the FSM that went down the sink around
>  08
> 
>  - When should a node initiate (i.e. not propagate) an increase in DTSN?
>  [Pascal] Can be upon an inconsistency detection, or upon an internal timer  per
> policy though that is not mandated. An inconsistency can be an RPF  check, a
> DAO entry not revalidated, a datapath validation failure. New  DSTN should be
> caped in time.
> 
>  - “Multicast DAOs MUST NOT include Transit Information options” (Section
> 8.6). Do you mean “MUST not include a parent address in the transit
> information option”?
>  [Pascal] Oups! Correct. We sometime need the lifetime.
> 
>  Best,
> 
>  Pascal
> 
> --
> Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/58>
> roll <http://tools.ietf.org/wg/roll/>
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:49:19 +0200

Hi Pascal,

So essentially we don't mandate anything in terms of processing DAO-ACKs. Correct?

Concerning the question "When should a node initiate (i.e. not propagate) an increase in DTSN?" are you going to add some text?
If nothing is mandated there as well, it means that nodes could decide never to increment their DTSN and hence send a DAO only when they change of DAO parent. 

This sounds pretty dangerous if no DAO-ACK are used or if DAO-ACK are used but nothing is done when they are not received. What do you think?

Best,
Mathilde

-----Original Message-----
From: Pascal Thubert (pthubert) 
Sent: jeudi, 22. juillet 2010 18:42
To: roll WG
Cc: JP Vasseur ([email-masked]); Mathilde Durvy (mdurvy)
Subject: Closing issue #58: Clarification on DAO

Dear WG

Legacy text removed.

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 10:16:55 +0200

> So essentially we don't mandate anything in terms of processing DAO- 

Correct.

> Concerning the question "When should a node initiate (i.e. not  
> propagate) an increase in DTSN?" are you going to add some text?
> If nothing is mandated there as well, it means that nodes could  
> decide never to increment their DTSN and hence send a DAO only when  
> they change of DAO parent.
>

Q for Pascal.

> This sounds pretty dangerous if no DAO-ACK are used or if DAO-ACK  
> are used but nothing is done when they are not received. What do you  
> think?
>

I don't think that we need to specify an algorithm here. We provide  
the mechanism, the rest is implementation specific (as in many other  
protocols).

Thanks.

JP.

>> ----------------------------- 
>> +------------------------------------------
>> ----------------------------- 
>> +------------------------------------------

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 23 Jul 2010 12:07:45 +0200

Hi Mathilde & JP

> > If nothing is mandated there as well, it means that nodes could
decide
> > never to increment their DTSN and hence send a DAO only when they
> > change of DAO parent.
> >
> 
> Q for Pascal.

We leave that to implementation as well.

Here's proposed text to be added in 'Configuration of RPL Parameters
related to DAO-based mechanisms'

"
          A RPL implementation MAY allow for configuring a set of rules
          specifying the triggers for DTSN increment (manual or
          event-based).
"

Do you think we should mandate more? It makes sense that an
inconsistency detection sometimes triggers a cache refresh, but that
certainly should be rate limited, and depend on the stability of the
network.

Pascal

> From: JP Vasseur [mailto:[email-masked]]
> Sent: Friday, July 23, 2010 10:17 AM
> To: Mathilde Durvy (mdurvy)
> Cc: Pascal Thubert (pthubert); roll WG
> Subject: Re: Closing issue #58: Clarification on DAO
> 
> 
decide
> > never to increment their DTSN and hence send a DAO only when they
> > change of DAO parent.
> >
> 
> Q for Pascal.
> 
are
> > used but nothing is done when they are not received. What do you
> > think?
> >
> 
the
> mechanism, the rest is implementation specific (as in many other
protocols).
> >> - "Multicast DAOs MUST NOT include Transit Information options"
> >> (Section 8.6). Do you mean "MUST not include a parent address in
the
> >> transit information option"?
> >
> >> - What actions need to be taken by a node that didn't get a DAO-
ACK
> >> response when setting the K bit?
> >
> > The text leaves that to implementation. Should not retry
indefinitely
> > though!
> >> From: [email-masked] [mailto:[email-masked]] On
Behalf
> >> Of roll issue tracker
> >> Reporter:  jpv@...            |       Owner:
> >> - What is the DAO parent selection criteria for OCP0? Same as for
DIO
> >> parents I assume.
> >> So yes, there's little choice but pick it as DAO parent as well.
> >> The draft  could
> >> - What actions need to be taken by a node that didn't get a DAO-
ACK
> >> response when setting the K bit?
> >> [Pascal] We have to refine that text in 11 for sure. Only new
> >> information  is sent asynchronously to the DAO parents while the
full
> >> information is  sent in
> >> constrained implementation sends the delta once and flag  it as not
> >> new without an ack, waiting for the next full information to  fill
> >> the gaps. So basically when something new is learnt, the storing
> >> router arms a timer to schedule a DAO. When the timer elapses, the
> >> router  sends all new information to the parents. The timer keeps
> >> elapsing for a  given parent till the parent acks the most recent
DAO
> >> sequence sent to it  or the router gives up. If the router gives
up,
> >> the parent is out of sync  till the next change or full information
> >> updates it. The path sequence  that circulates via other parents
that
> >> are not out of sync is fresher and  enables the ancestors to select
> >> the usable path.
> >>
> >> [Pascal] Can be upon an inconsistency detection, or upon an
internal
> >> timer  per
> >> DAO entry not revalidated, a datapath validation failure. New  DSTN
> >> should be caped in time.
> >>
> >> - "Multicast DAOs MUST NOT include Transit Information options"
> >> (Section 8.6). Do you mean "MUST not include a parent address in
the
> >> transit information option"?

---

From: JP Vasseur <[email-masked]>
Date: Fri, 23 Jul 2010 12:33:07 +0200

Hi,

On Jul 23, 2010, at 12:07 PM, Pascal Thubert (pthubert) wrote:

> Do you think we should mandate more?

Nope, let's add it to Section 16.

> It makes sense that an

Which is a tuning issue.

JP.