Subject: Re: [Roll] More questions on DAO

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 12 Jul 2010 16:30:08 +0200

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

---

From: JP Vasseur <[email-masked]>
Date: Tue, 13 Jul 2010 11:15:35 +0200

Since this leads to clarifications to be added to -11, I have opened a  
ticket to keep track of it.
No need for action item on the third bullet since the FSM is not part  
of that ID.

Thanks.

JP.

On Jul 12, 2010, at 4:30 PM, Pascal Thubert (pthubert) wrote:

> Hello Mathilde
>
> - What is the DAO parent selection criteria for OCP0? Same as for  
> DIO parents I assume.
> 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  
> 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.
>
> 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
>
> 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”?
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll