Re: [Roll] some comments on draft-thubert-dao-projection-00.txt

"Pascal Thubert (pthubert)" <> Sat, 04 July 2015 20:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6525C1A005B for <>; Sat, 4 Jul 2015 13:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GMgkCmDGHdoE for <>; Sat, 4 Jul 2015 13:28:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 567D11A0062 for <>; Sat, 4 Jul 2015 13:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5156; q=dns/txt; s=iport; t=1436041711; x=1437251311; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nvZ3nWM1V4UadBKlTF+LV1ti1QjBd0tvwhy8XzLe4uw=; b=FvHkGnIEA8bJ/PMwvDYiSDjvKpjJo8JU6qFBao6MNqO1qt4mvZuO7VQR mhamE9VvKxoLHxdb01tgxLT/aZeDTQq5I1RqVW5+1UxtAB9n3RPRho4dq PI1zTRnLJwoxhQ17WnlGSVtq+bg01YV0NGrXobUHOfuKmhzQJ8r6CZ3HI k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,407,1432598400"; d="scan'208";a="12649979"
Received: from ([]) by with ESMTP; 04 Jul 2015 20:28:30 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t64KSUnn005156 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Sat, 4 Jul 2015 20:28:30 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sat, 4 Jul 2015 15:28:29 -0500
From: "Pascal Thubert (pthubert)" <>
To: Routing Over Low power and Lossy networks <>
Thread-Topic: [Roll] some comments on draft-thubert-dao-projection-00.txt
Thread-Index: AQHQtl4uhnM3ZZux4UKM8k7V/iC9hJ3Lwz3s
Date: Sat, 4 Jul 2015 20:28:29 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Roll] some comments on draft-thubert-dao-projection-00.txt
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, 04 Jul 2015 20:28:33 -0000

Fantastic Michael!

I'll answer in the list but many thanks already!


> Le 4 juil. 2015 à 15:34, Michael Richardson <> a écrit :
> <Chair hat off>
> Pascal, thank you for this document.
> I especially appreciated your figure 2, the way that you numbered the nodes
> with their gross rank as the the tens part.
> You write on page 8:
>   The root sends the DAO directly to the last node in the segment,
>   which is expected to be able to route to the targets on its own.
> It would be good to make it clear which direction one counts the "segment"
> to know which one is last.  I don't like "segment" here, I think it's
> a routing path...  Could you define segment if you think it's the most
> natural term to use.
> (There are also some articles like "the" missing in places, btw)
> Then you write:
>   The node strips the last Via Information option which corresponds to
>   self, and uses it as source address for the DAO to the predecessor.
> I think that what is described, to use the numbering in your example,
> is that the root would send a message to 41, with a target=51,
> list of VIAs:11,22,31,41 and *then* 41 would send a DAO to 31,
> with a list of VIAs 11,22,31, etc.
> It's the "then" above part that I *think* is a critical part of the protocol,
> and is perhaps not clearly spelled out.  I wasn't entirely sure if I
> read it correctly.
> In the case where nodes have different downstream and upstream addresses
> (because, for instance they had different radios), then there might be
> some confusion and maybe both hops should be listed.  I recall I posted a
> thread asking about that a year or so ago, but I don't recall what the
> conclusion was.
> But, then in the example on page 9, after sending these Via-DAOs to
> 45 and 46, it says:
>   The root
>   may then send a DAO to node 35 indicating targets 55 and 56 a Via
>   segment (13, 24, 35) to fully optimize that path.
> While the root had initially optimized the 45/46 out the routing
> header with the first set of Via-DOAs (do you have a name for these messages?
> Projected-DAOs? maybe), couldn't that set of DOAs have included 13,24
> in the list as well?
> Alternatively, could the root have sent a single Via-DOA with destination
> *35* to 24, with the route 13,24?   That would have resulted in a routing
> header like:
>       ROOT -> 35
> since 13 and 24 should be able to reach 35 in a loose source route,
> and 35 would know how to reach 55 and 56?
> ****
> in section 3.1, the description of the VIA extension, you write:
> Option Length:  Variable, depending on whether or not Parent Address
>         is present.
> But the only variability I saw in the extension was whether the child
> address was 8 bytes or 16 bytes.  It seems that if you are going to
> optimize this, you might as well also offer an option for the Child
> Address to be 2 bytes (the last two bytes).
> **** DAO
> I don't fundamentally see a reason why DAO is used.  I guess it has the
> right properties, but I think that a new message type could be defined
> equally well (as well as a new ACK), even if it just replicates the exact DAO
> structure.  It seems that the ACK is mandatory (K=1).
> I would prefer that DAOs always flow towards the root, and DIOs away.
> It would make analysis of what is going on easier.
> These DAOs in some way flow towards a node with root-like storing-like
> abilities, so I can see why it was elegant to reuse DAO for this.
> **** incremental deployment
> Use of a new MOP makes deployment of this a flag day.
> I don't think that this is necessary, although some niggling doubt going back
> to the mixed storing/non-storing discussion of 2011 remains...
> I think that the DAOs that come from nodes that are able to act as Route
> Projection nodes could indicate that capability, and furthermore, indicate
> the number of routing slots they currently have free.
> It would be advantageous perhaps to explicitely number the routing slots.
> My initial thought is that would permit the subsequent DAOs to perhaps
> include a count of how many times the Projected route was used: once the
> DODAG root pushes traffic away from the root with these projected routes,
> it can no longer count how much traffic is occuring, so it should get
> reports "from the field" so that it can decide whether to keep those routes.
> Explicitely numbering the routing slots could be problematic I agree,
> but it would allow the DODAG to manage them directly rather than the implicit
> process that the VIA option's Path Sequence is doing.
> The Path Sequence processing needs an example, btw.
> --
> Michael Richardson <>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> _______________________________________________
> Roll mailing list