Subject: [Roll] [roll] #58: Clarification on DAO

From: "roll issue tracker" <[email-masked]>
Date: Tue, 13 Jul 2010 09:14:13 -0000

#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/>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 23 Jul 2010 10:41:17 -0000

#58: Clarification on DAO
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:        
     Type:  enhancement      |       Status:  closed
 Priority:  major            |    Milestone:        
Component:  rpl              |      Version:        
 Severity:  In WG Last Call  |   Resolution:  fixed 
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 From: "Pascal Thubert (pthubert)" <[email-masked]>
 Date: July 22, 2010 6:42:21 PM CEDT
 To: "roll WG" <[email-masked]>
 Cc: <[email-masked]>, "Mathilde Durvy (mdurvy)" <[email-masked]>
 Subject: Closing issue #58: Clarification on DAO

 Dear WG

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

 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.

 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

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/58#comment:1>
roll <http://tools.ietf.org/wg/roll/>