Re: [Roll] question about DAO-ACK

Michael Richardson <> Sat, 19 July 2014 18:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0CE6E1B29AC for <>; Sat, 19 Jul 2014 11:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.007
X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7cbps1a2o9TU for <>; Sat, 19 Jul 2014 11:35:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE5461B2854 for <>; Sat, 19 Jul 2014 11:35:02 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id E7A8D2002A for <>; Sat, 19 Jul 2014 14:36:27 -0400 (EDT)
Received: by (Postfix, from userid 179) id 67BA263B0E; Sat, 19 Jul 2014 14:34:59 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 3631263AED for <>; Sat, 19 Jul 2014 14:34:59 -0400 (EDT)
From: Michael Richardson <>
To: Routing Over Low power and Lossy networks <>
In-Reply-To: <>
References: <> <>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 19 Jul 2014 14:34:59 -0400
Message-ID: <>
Subject: Re: [Roll] question about DAO-ACK
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 19 Jul 2014 18:35:05 -0000


Pascal Thubert (pthubert) <> wrote:
    >> Or is it enough that B says, "okay, I got you", and then takes
    >> responsibility for sending reachability information on its own?

    > [PT] The design was the latter, that it was OK for B to say "I got
    > you".  Today it is mostly an alternate to MAC layer Ack, but the design
    > is richer than that since a status code is provisioned though not used.
    > A negative status code could say things like "I'm overloaded with DAO
    > state already" or "I'm out of battery".

Yes... so if the sender does set the K bit, they might still get the MAC
layer ACK, which tells them the packet was received, but can not tell them
anything about being overloaded, etc.   What reason would there be not
to set the K bit?

In non-storing mode, if you set the K bit, can you expect to ever get a
negative reply,  if the root is overloaded, or otherwises refuses to accept
your DAO?
(You can't get a reply, because the root can't route to you, since it didn't
accept your DAO...)

    >> The problem I have with not waiting is that if C thinks it is on the
    >> network when it gets the DAOACK, it can start sending traffic upwards,
    >> but downward packets would get lost for awhile.  Further, it is going
    >> to start sending DIOs, and start attracting traffic from other nodes
    >> when really, it isn't ready to do so.

    > [PT] This could effectively happen; mostly if you are considering the
    > join process.  This suggests that leveraging a tunnel from a joined
    > parent could effectively be a good idea there (eg piggy backing join
    > info to system/security manager on DAR/DAC message).  Also that
    > piggybacking security info to the DAO could effectively improve the
    > trust in the DAO content and ensure that the next phases of join
    > process can be responded to.

I was not thinking about any of the (initial) join process; it could just be
a node rejoining after a movement, an RF change reveals a new parent, or
just a cold restart of the node.

    >> 3) in the non-storing case, if a parent (B) of C, in fact had multiple
    >> interfaces, node C might not see the interface that is closer to A,
    >> and can only, in the Transit option, indicate the interface that it
    >> does see.  This implies that root A, may have to do two lookups to
    >> figure out where Bdown is, as it likely only has route to Bup.

    > [PT] You seem to imply that BDown would be advertised as reachable via
    > BUp.

Yes, that's right.  The root would have a (source) route to Bup (whether
direct or via other layers of the mesh), and another source route to Bdown
(via Bup)
The important thing is that C can not mention Bup, it can only mention Bown.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-