Re: [Roll] Call for reviews for draft-koutsiamanis-roll-traffic-aware-of-00

Michael Richardson <> Wed, 24 July 2019 14:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A49FF1202E1 for <>; Wed, 24 Jul 2019 07:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xG0A_xYAbxgU for <>; Wed, 24 Jul 2019 07:28:30 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id E5960120320 for <>; Wed, 24 Jul 2019 07:28:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3076538193 for <>; Wed, 24 Jul 2019 10:28:09 -0400 (EDT)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 7F1C79BC for <>; Wed, 24 Jul 2019 10:28:23 -0400 (EDT)
References: <>
From: Michael Richardson <>
Message-ID: <>
Date: Wed, 24 Jul 2019 10:28:23 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Roll] Call for reviews for draft-koutsiamanis-roll-traffic-aware-of-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 14:28:41 -0000

On 2019-06-06 6:14 a.m., Ines Robles wrote:
> Dear all,
> We would like to have reviews 
> for draft-koutsiamanis-roll-traffic-aware-of-00.

I have read it. It seems like it is way overdue to have this work.

} The difficulty lies in the method of partitioning the traffic to 
multiple parents.

But, what about the cost of the downward traffic?  We have to attach to 
one parent or the other to get traffic routed right.  Maybe in 
non-storing we can do something smarter with projected-DAO?

It's good that [I-D.ietf-6tisch-enrollment-enhanced-beacon] is 
referenced.  But maybe 
also needs to be updated to
take into account the remaining throughput priority.

I think that the document would benefit from distinguishing between the 
cases where a node has already enrolled from the situation where the 
node needs to enroll.  The set of information is not the same.