[Roll] question about DAO-ACK

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 July 2014 20:23 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228181B27E3 for <roll@ietfa.amsl.com>; Wed, 2 Jul 2014 13:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.029
X-Spam-Level: *
X-Spam-Status: No, score=1.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_MIME_NO_TEXT=0.01, T_TVD_MIME_NO_HEADERS=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO_eCy_rCr_f for <roll@ietfa.amsl.com>; Wed, 2 Jul 2014 13:23:04 -0700 (PDT)
Received: from tuna.sandelman.ca (unknown [209.87.249.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF01E1A0240 for <roll@ietf.org>; Wed, 2 Jul 2014 13:23:03 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 087552002C for <roll@ietf.org>; Wed, 2 Jul 2014 16:23:33 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 3D04E63B0F; Wed, 2 Jul 2014 16:23:01 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2BB7263B09 for <roll@ietf.org>; Wed, 2 Jul 2014 16:23:01 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Attribution: mcr
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: Wed, 02 Jul 2014 16:23:01 -0400
Message-ID: <5003.1404332581@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/xCoMAaVpQLUJKVFd-jIXZzYXfWw
Subject: [Roll] question about DAO-ACK
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jul 2014 20:23:05 -0000

<REMOVES CHAIR HAT>

Given:
        - a storing implementation
        - DAO-ACKs requested
        - three nodes: A <- B <- C. A is the root.

C sends a DAO with the K bit set to selected parent B.
B will need to send a DAO to A indicating that it knows about C.

Question
1) should B wait until it receives a DAOACK from A before
   sending a DAOACK back to C?
   (before you answer, consider the the tree could be very
   deep, and that this implies that the intermediate nodes
   have to keep potentially many outgoing DAOACKs in a queue)

   Or is it enough that B says, "okay, I got you", and then
   takes responsibility for sending reachability information
   on its own?

   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.

2) if B recieves a DAO with the K bit set from, does this imply
   that it ought to set the K bit to its parent?
   If the answer is no, and you answer the question (1) that B ought to
   wait until it has heard from A before answering, but B
   has a policy of not setting the K bit, should B then
   answer immediately?

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.

4) what is the use case for the RPL Target Descriptor?

======

The DAO-ACK mechanism is pretty important to assure bi-directional
reachability, and the security-threads document makes reference to it.

I had not clued in that the K bit was optional before.


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-