[Anima] ANIMA ACP -08 -- estimating depth of DODAG in storing mode

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 02 August 2017 06:37 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A112126CB6; Tue, 1 Aug 2017 23:37:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TA86fAc6jtmO; Tue, 1 Aug 2017 23:36:58 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF7D124C27; Tue, 1 Aug 2017 23:36:58 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0BF282009E; Wed, 2 Aug 2017 02:38:48 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8A6F08076D; Wed, 2 Aug 2017 02:36:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima@ietf.org, roll@ietf.org
cc: Pascal Thubert <pthubert@cisco.com>
In-Reply-To: <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com>
References: <150044138257.25233.12391471568614147773@ietfa.amsl.com> <f5e84812-c2fa-cc16-4105-20f7791110f4@gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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-sha256; protocol="application/pgp-signature"
Date: Wed, 02 Aug 2017 02:36:57 -0400
Message-ID: <27113.1501655817@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Tm2nDpO34cb-EY_x9yemUUxaxBI>
Subject: [Anima] ANIMA ACP -08 -- estimating depth of DODAG in storing mode
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2017 06:37:00 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > [One detail however:

    >> The loop-count MUST be sete to 255.  When an ACP node
    >> receives the M_FLOOD, it will have been reduced by the number of hops
    >> from the EST server.

    > I don't like that. The role of the loop count is loop prevention,
    > so it should be set to a reasonable upper bound on the "radius"
    > of the network. GRASP has two measures for loop detection, this
    > one and detection of duplicate session IDs, but that was
    > intentional redundancy.]

If we were using RPL in non-storing mode, we'd get DAO messages from the
leaves directly to the root indicating their parent.  The DODAG root would
therefore know exactly what the deepest leaf was.  That would be the radius
From the root to the furthest node, but of course discovery might happen from
edge to edge, so the longest path would therefore be 2x that size (up the
tree to the top and down again).

As we are using RPL in storing mode, the DAOs are summarized at each level,
we won't know that information.  That's kind too bad I think, because each
node knows how deep it is, they just don't report it to the root in anyway.

It would be easy to add a CHILD_MAX_RANK DAO option to the DAO packet.
It wouldn't make it to the top unless all nodes supported it, but it still
might be worth writing it down.

Unless someone else can figure out a way with existing information for a
DODAG root to know how deep the network is?

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