Re: [Roll] updating DAO caches - a proposal
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Roll] updating DAO caches - a proposal
> Date: Mon, 23 Nov 2009 20:44:20 +0100
> From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
Pascal,
I have to consider your response to my proposal. For
now I will just respond to points you made about DAOs
in the current draft.
> >> IF we all agree on the above, that is sending only to one preferred
> >> parent, then there can only be one child that advertises a DAO
> >> destination. Thus there can be only one route to a destination. Thus
> >> if 2 children advertise a same destination, one is wrong.
> >
> >Not necessarily, if the destination is not on the subnet.
> >There may be be redundant routes.
>
> Aie, I did not have that in mind; should we support that?
We do not prohibit it, which I would think means that we
support it. I don't care one way or the other.
> >As an aside, the DAO mechanism depends on the link layer
> >being 100% reliable. If the link layer can lose messages a
> >number of changes will be necessary. The ROLL document
> >needs to be explicit about the link-layer requirements.
>
> DAOs are repeated over and over. If one indicating a change is missed,
> there is a service interruption till the next
If DAOs are sent repeatedly, what is the purpose of the `D'
destination advertisement bit? Is it just to synchronize
the sending of new DAOs rather than waiting for them to be
sent?
Also, in -04, section 5.9.1.3. says:
When sending a destination advertisement to a DA parent, a node
includes the DAOs for prefix entries not already reported (since the
last DA Trigger from an DIO message) in the Reachable and Connected
lists, as well as no-DAOs for all the entries in the Unreachable
list.
This indicates that a new DAO only includes new information.
Prefix entries sent in an earlier DAO are not included in a
later one.
-Richard Kelsey
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.