Re: [Roll] question about DAO-ACK

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 15 July 2014 08:33 UTC

Return-Path: <pthubert@cisco.com>
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 914F81A0368 for <roll@ietfa.amsl.com>; Tue, 15 Jul 2014 01:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Js2RE_7oXnRB for <roll@ietfa.amsl.com>; Tue, 15 Jul 2014 01:33:05 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8541A001A for <roll@ietf.org>; Tue, 15 Jul 2014 01:33:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4243; q=dns/txt; s=iport; t=1405413185; x=1406622785; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=0pvB/Z1iJt3eOH/CTHHU2xiH/9b90MScxlExNsdMVO0=; b=Ig7/iiGdF8Yv6FNncs1B/nJv9l0D6JiP/JjI7dVA3vnEHDJiPlGjbJpq IIniqRcIFSEFOpVG1mgesSZNKd3D8ljKbJ01OoK5wKLTlClUgZLpl78El Lexy38bBkGTNSxmSnDoKpjfBQ9oN53dM5ewMwgKLeeSXTE6ymoeFF74MF A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAJzmxFOtJA2H/2dsb2JhbABZgw6BLckhAYEIFnWEBAEBAwE6RAsCAQgiFBAyJQIEG4gyCMkwF45jNziDLYEWBa84g0SCMA
X-IronPort-AV: E=Sophos;i="5.01,664,1400025600"; d="scan'208";a="340080769"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2014 08:33:04 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6F8X4In017659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <roll@ietf.org>; Tue, 15 Jul 2014 08:33:04 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.24]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 03:33:03 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] question about DAO-ACK
Thread-Index: AQHPljNyNFRTP6zvKEq5hluTFJmycZug1v3A
Date: Tue, 15 Jul 2014 08:33:03 +0000
Deferred-Delivery: Tue, 15 Jul 2014 08:33:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842CA9F5C@xmb-rcd-x01.cisco.com>
References: <5003.1404332581@sandelman.ca>
In-Reply-To: <5003.1404332581@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.216.64]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/roll/ZgO44h__kvg2rnt0Q2dXHaBRnkY
Subject: Re: [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: Tue, 15 Jul 2014 08:33:06 -0000

Hello Michael:

Please find below what at least was in the intention in the spec:

 
> 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?
> 
[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".

>    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.

> 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?

[PT] No, this is not the case. The design for the K-bit was a one-hop thing that may depend on the link properties. 

> 
> 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. Could be, e.g. in a mobility scenario where 1) you have many BDowns and 2) BUp changes parents frequently; in which case doing this would save advertisements: in case of a movement you'd only advertise the change of parent of BUp. But the more common case is that B would advertise all its addresses as being reachable via its parent, but concatenating multiple target options for all its interfaces and then placing a transit option for the parent that is factorized.

> 4) what is the use case for the RPL Target Descriptor?
[PT] The intent was route tagging. I did not get feedback that anyone is using it so far, but it is a classical thing and probably was a good idea to support it from the start. A tag may be placed to influence routing based on policies, and redistribution between protocols or domains. A tag could for instance indicate which RPL domain or subdomain the node is effectively attached to. In classical networks you want to stay within the same area/ routing protocol domain and tags are used to prevent reinjection into the original domain from an different domain. With RPL, if you have a fast (OSPF / Ethernet backbone) and a slow network (RPL LLN) then you may have more complex / asymmetric rules, since going though the fast network is probably a good idea.

Cheers,

Pascal