Re: [Roll] Review of draft-ietf-roll-aodv-rpl-12

Charles Perkins <charliep@lupinlodge.com> Wed, 15 June 2022 00:34 UTC

Return-Path: <charliep@lupinlodge.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3419AC14F75F; Tue, 14 Jun 2022 17:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lupinlodge.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzDU3rnQDKRz; Tue, 14 Jun 2022 17:34:01 -0700 (PDT)
Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [185.56.85.143]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00CBC14F719; Tue, 14 Jun 2022 17:34:00 -0700 (PDT)
Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se22.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <charliep@lupinlodge.com>) id 1o1Gyr-0005X2-00; Tue, 14 Jun 2022 19:33:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WYDebuq7JGrneMSwGptSB6XBkgf40pY6lKnYsuM/2hY=; b=VsrJD5051o963BB5unjEMmFai1 kOQu1d0YnHym/8jaCWByMUX5b7dQoXvBTZZaQvGAAO28JK8zVgH41gR5tJkPpLaMHz15PBdUuy4K7 4IBYJzd5oDdIelcsqXD3DYTNB4EDisHpN2rjO2VFw/1Qe9F6rfJyQdV8WcSFYK6KO//c=;
Received: from [99.51.72.196] (port=59427 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from <charliep@lupinlodge.com>) id 1o1Gyl-0003Qz-MM; Wed, 15 Jun 2022 00:33:51 +0000
Message-ID: <9762fb38-4b38-15b4-7038-645e6e57f664@lupinlodge.com>
Date: Tue, 14 Jun 2022 17:33:49 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
Cc: roll-chairs@ietf.org, "draft-ietf-roll-aodv-rpl@ietf.org" <draft-ietf-roll-aodv-rpl@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
References: <f7a504ac-764d-09e9-d969-067e6a21646a@mimuw.edu.pl> <51f1c414-0e02-f09f-83a2-6efb6a19a352@mimuw.edu.pl>
From: Charles Perkins <charliep@lupinlodge.com>
In-Reply-To: <51f1c414-0e02-f09f-83a2-6efb6a19a352@mimuw.edu.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: 35.208.206.246
X-SpamExperts-Domain: giowm1055.siteground.biz
X-SpamExperts-Username: 35.208.206.246
Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.11)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8zLiLkVrbax7QMni8Yp868PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5zoDAyBrzZtaFVM50/0i6hHUbY0AMtbXuRv3/rWj4hlXMxt 8fXLaDGkWzue2uPnGL5lDiV/6GkwjwIba6VZBJrUjrVpFP1QET1296sHpQT4HXYrA/bT8fyUZhGx W0A+ngfMXQ8Q1osOCIWC0ia8j8cL3BhSCI1Ay0Cg80Qgmy2FZJ5/EQP8uO+maAF+OKAPGi1Wd62Q 4tf7w1n56gL5R3iTw/vpBwazsuGd2DYuMOMHrkKMjZSihVDQnKMV5s+3THm36OSHHaHG6xkR5l7D T3fCa+qndoz2QK+krFr9K+NKNVk6xev7rH7B6ntBmUfHETwcgFcwV0HUFwydSzwo8f/O7DgzTQVm jsGWMqZuQKevgUdX9lgZ8EzqS/IY6P98izR3ZBqYO9VwKPND/pdtt3G4Z66lhh3M+bth9ENpQs5T aTYms7xC/xECurYzBZo2eH5S4gXbKfTeztNLeCGba+AGlvk+fp+1BlUr0rwQCOffuxSDr14Ng17a K0KVPdLtuNBQKjk9kmwtxjkWY2Gn4kPGVpINCrrmyHtjjf0CHFiJxc8p7Gcft0pju97pHR2T/i2g maHTheyDjAmLwR4gkKNs9cHYfrSl3Mkb0PGUVIgdCaFfbJCeQvjdrdga95yZyOAxjDo7UOXScGrq Gu7U9hh3ztRkHkONmyNOdgAokG3RBgJROOjBcedTTbiG1LlVPGBELBPRhXwJmlLcpcL+TmytehIq UczFWeS6sE8e1b5/Ul2fSwG/TvAo5y93wcziq9kUHVjFiP3k5taqH3q+LEAzEnhDHJKGk31J8viU qt2NBAh1AuFwXCdmPXMozUTQXZbRjdK3JtbOY4V5u4SqNrbdQZgwQAQ9NfskToW8laQ6TfDfu1ad yFMRmNVy9odfPPD68fXQp5/v+hqOLv5XS6YJGFHLnycar03tfqEW4rzzPz9HEcE3EnUZfUBirZef T+lRBYPxlSXpboZstVJFY0USX6kB0St0VpNkvfO7nu5Nj3pQVDeuo13gp393GoGMoA4ccBIk1Sag 4dKiqCrF8eZZiMzi6RIEIVGE+p7rY1VZwfqXu2WjVjtIIoX4BuOBpu4+F8P5bOuLMuKMkpaXrVo9 1XFg+oFC66uUddqF1evH/8tIIlDgLnONx7Kdl44U+7K7/jdDyHSU7f7GAcSPtGb5ZYtfZltBvdQk qKESagO7CAllBCdBWmiHNSPDQg6yy20/vS8CPZs5vahln6dW+qLKRsVMXiUcQ53RjrC3sPjcc79E XDRMJhTEXdCGBhx+InM=
X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/L42eYYsXS3xwnv9NCf59bfP_S1g>
Subject: Re: [Roll] Review of draft-ietf-roll-aodv-rpl-12
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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, 15 Jun 2022 00:34:05 -0000

Hello Konrad,

After several iterations, we have finally prepared these resolutions for 
your much appreciated comments on our draft.


 > # Major issues / questions:
 >
 > 1. For garbage-collecting RREQ- and RREP-DODAGs that are no longer
 > necessary, a timeout solution is used: the L field in the RRE(Q|P)
 > messages. Although this is not formulated explicitly in the draft, from
 > the format of the messages, I assume that the timeout is counted locally
 > and independently by each node, from the moment it joins the
 > corresponding DODAG. In particular, depending among others on the
 > network topology, the configuration of Trickle, and the underlying
 > link-layer, a node may start a timeout for a DODAG after another has
 > already left this DODAG. This is dangerous as it may lead to situations
 > in which information about a DODAG is never garbage-collected because
 > nodes that leave the DODAG may rejoin it upon hearing information from
 > other nodes that are still in the DODAG. I would opt for an alternative
 > solution or at least some poisoning- or grace-period based approach. In
 > addition, it would be nice to have in the draft a potential risk
 > analysis regarding the configuration parameters of the solution.

    o  We will create another configurable parameter called REJOIN_REENABLE,
       with a relatively long default value. Time is indeed counted locally
       and independently by each node.


 > The synchronized termination of DODAG is hard unless we introduce time
 > information is carried in the DIO packets which in turn calls for a time
 > synchronized network.
 >
 > For AODV-RPL to work, OrigNode needs to set L field such that the 
DODAG will
 > not prematurely timeout during data transfer with the TargNode. For 
setting
 > this value, it has to consider factors like, Trickle timer, TargNode hop
 > distance, network size, link behaviour, expected data usage time, and 
so on.
 > Once DODAG lifetime is exceeded, stale RRE(Q|P) DIO that might be in
 > circulation need to be discarded by TargNode and OrigNode. Eventually 
all the
 > intermediate nodes timeout.


    The transmission of RREQ-DIO obeys the Trickle timer [RFC6206]. If
    the length of time specified by the L field has elapsed, the OrigNode
    MUST leave the DODAG and stop sending RREQ-DIOs in the related
    RPLInstance.  OrigNode needs to set L field such that the DODAG will not
    prematurely timeout during data transfer with the TargNode.
    For setting this value, it has to consider factors such as
    Trickle timer, TargNode hop distance, network size, link
    behaviour, expected data usage time, and so on.


 > 2. What is the rationale behind deleting by TargNode the DIO ART Option
 > containing its address (and then taking address set intersections when
 > propagating the DIOs)? What problem do these mechanisms aim to solve? A
 > node can still receive DIOs along multiple paths. It should be able to
 > choose the "most desirable one". Deleting the target address and using
 > the intersection mechanism described in Sect. 6.2.2. may actually
 > preclude this behavior if the "most desirable path" for a TargNode is
 > not the one it obtains first. For example, consider the following
 > circular network:
 >
 > A1 - OR - B1
 > |         |
 > A2        B2
 > |         |
 > T1 - T2 - B3
 >
 > with OR = OrigNode, T1 = TargNode1, T2 = TargNode2, and (A|B)* acting as
 > intermediate routers. Suppose that the path over nodes B* is the most
 > desirable one for both T1 and T2. Now, consider the following scenario.
 > T1 receives an RREQ-DIO first from A2 and joins the RREQ-DODAG. It then
 > propagates the DIO to T2 but with ART Option with its own address (T1)
 > removed. In effect T2 also joins the RREQ-DODAG, remembering however
 > that the last RREQ-DIO contained only T2. Now, T2 finally receives an
 > RREQ-DIO from B3. It does not propagate to T1 this path because: (1) it
 > removes its own address from the DIO and (2) the address of T1 is not
 > included because of taking the intersection of the address sets T2
 > received in the DIOs along the two paths. In effect, T1 will never learn
 > the most desirable path. Is this what is expected to happen or am I
 > missing something? Again, it is not clear to me what the goal of the
 > removal and intersection is. In the end, original RPL creates routes
 > from multiple targets (all nodes) to the root, so why does this protocol
 > require dynamically removing the targets?

The proposed scheme is motivated by a familiar trade-off between optimal
behavior and scalability.  AODV-RPL leans heavily towards scalability
while trying to achieve good (albeit not optimal) performance.
Once all the TargNodes listed in ART are reached, the proposed scheme 
prevents
DIO messages circulating in the network.   This reduces
congestion, routing overheads and state maintenance.


 > 
-----------------------------------------------------------------------------
 >
 >
 > 3. A related concern applies to Sect. 6.2.6., more specifically, to the
 > second statement: "If, on the other hand, TargNode was already
 > associated with the RREQ-Instance, it takes no further action and does
 > not send an RREP-DIO." To me, it implies that TargNode replies with
 > RREP-DIO to the first RREQ that results in its joining the corresponding
 > RREQ-DODAG. In particular, if it learns about a better path to OrigNode,
 > it does not use this path instead of the first path it joined. Again, am
 > I missing something or is this intentional? If so, it seems somewhat
 > conflicting with the second paragraph of Sect. 6.3, which allows the
 > node to wait for RREP_WAIT_TIME before replying. Trying to combine these
 > two sections, my understanding would be that TargNode sends an RREP to
 > the best path that it is able to learn within the RREP_WAIT_TIME. If
 > this was the intention, then what is the rationale behind setting the
 > default RREP_WAIT_TIME to 0 for L = 0? This would imply that for an
 > RREQ-DODAG that is to be maintained infinitely long, only the first path
 > to OrigNode learned by TargNode is considered. In general, why not
 > introduce into the protocol algorithms for TargNode to update its path
 > when it learns a better one? This would also require updating RREP
 > propagation, which is again done only for the first received message
 > (per Sect. 6.4).

New language:

    If TargNode is not already associated with the RREQ-Instance, it
    prepares and transmits a RREP-DIO, possibly after waiting for
    RREP_WAIT_TIME, as detailed in (Section 6.3).

    The nodes follow Trickle timers and the correspnding DIO message
    transfers as specified in RFC 6550.  AODV-RPL does not modify this
    behavior.


 > 4. It is not entirely clear to me how Trickle timers govern
 > transmissions of multicast RREQ/RREP DIOs. In particular, when the
 > timers are reset? How is this policy influenced by the fact that, in
 > line with my previous comments, in principle a node reacts only the
 > first RREQ/RREP DIOs that cause its joining the corresponding DODAGs.
 > Perhaps a bit extended discussion of these issues could be provided in
 > Sect. 8.

    RREQ-Instance/RREP-Instance multicast uses trickle timer operations
    [RFC6206] to control RREQ-DIO and RREP-DIO transmissions.  The
    Trickle control of these DIO transmissions follows the procedures
    described in the Section 8.3 of [RFC6550] entitled "DIO
    Transmission".  If the route is symmetric, the RREP DIO does not need
    the Trickle timer mechanism.

    Whether or not an intermediate node should be allowed to update its
    route to OrigNode and retransmit a "better" RREQ is an interesting
    point of discussion, outside the scope of this specification.


 > 5. There is also no discussion in the draft of a situation in which a
 > node has no resources to join a RREQ- or RREP-DODAG. While in the case
 > of RPL, this is arguably not that relevant, in the proposed protocol,
 > there may be many concurrent DODAGs, and hence it is intuitively more
 > likely that some nodes may lack resources to handle all DODAGs.

    If a node does not have resources, it drops the RREQ.  A node cannot 
join
    the DODAG unless it has enough resources to send a corresponding RREP.


 > # Smaller issues / nits:
 >
 > Page 4, definition of "AODV": add a space between "Routing" and 
"[RFC3561]".

Done.

 >
 > Page 4, definition of "DODAG RREQ-Instance": "control message
 > transmission" (hard to parse) => "transmission of control messages"

Done.

 >
 > Page 4, definition of "DODAG RREP-Instance": the same as above

Done.
 >
 > Page 6, text ""RREQ-DIO message" means the DIO message from OrigNode to
 > TargNode" is confusing as DIO messages are link-local. Changing this to
 > ""RREQ-DIO message" means a DIO message from OrigNode toward TargNode"
 > may sound better. The same applies to the next statement.

Done.

 >
 > Page 8, definition of "L": "the time" => "time"

Done.

 >
 > Page 8, definition of "MaxRank" is confusing. The name would suggest
 > that this is the maximal allowed value, whereas the text implies that
 > this is the minimal disallowed value. Perhaps the name "MaxRank" could
 > be changed to something else, like "RankLimit".

Done.


 > Page 8, "Other nodes MUST NOT join RREQ instance if its own Rank would
 > be" => "Any other node MUST NOT join..."

Done.


 > Page 9, definition of "L": "The lifetime of the RREP-Instance MUST be
 > shorter than the lifetime of the RREQ-Instance to which it is paired.
 > What if the lifetime of the RREQ-Instance is infinite? In general, why
 > such a requirement?

Revised text:
       2-bit unsigned integer defined as in RREQ option.  The lifetime of
       the RREP-Instance SHOULD be shorter than the lifetime of the RREQ-
       Instance to which it is paired.

The motivations for OrigNode's choice for the value of the L field
are considered likely to also pertain to the RREP-Instance, including the
case when OrigNode sets the L field to be infinite.  The mandate was
softened to "SHOULD" in case other considerations, beyond the scope of
this document, are relevant to the TargNode's choice.


 > Page 14, the last paragraph, text starting from "It does this..." is
 > unclear to me. What happens in the end with MaxUseRank? (This is the
 > first and only paragraph where this symbol occurs.)

"MaxUseRank" changed to be  MaxUsefulRank -- a bit more intuitive.

 > Page 18, the last paragraph: term "shift" is somewhat misleading (to me
 > it describes bit shifts: right shift, left shift). Perhaps "offset" or
 > "delta" would be better.

I changed the name from Shift to Delta and rewrote the relevant text.

 >
 > Page 18, the last paragraph: The text starting with "In RREP-DIO option,
 > the Shift field..." seems confusing. More specifically, it is not clear
 > to me what is shifted/offset: (1) does the receiving node have to offset
 > the RPLInstanceID in the RREP-DIO to obtain the RPLInstanceId in the
 > RREQ-DIO OR (2) is the RPLInstanceID in the RREP-DIO equal to the
 > RPLInstanceID in the RREQ-DIO but the receiving node should offset the
 > former so as to avoid conflicts? I guess it is (1) but am not sure based
 > on the text. In particular, what "original" means there?

New terms "RREQ_InstanceID" (RPLInstanceID, OrigNode_IPaddr) and
"RREP_InstanceID" (RPLInstanceID, TargNode_IPaddr) will be added to the
Terminology section to resolve this.  OrigNode allocates the local
RPLInstanceID for the RREQ_InstanceID, and likewise TargNode
for the RREP_InstanceID.

 > Page 18, the last paragraph: "would prevent intermediate routers to
 > distinguish" => "intermediate routers could not distinguish".

Done.

 >
 > Page 20, Sect. 6.4.4., "Otherwise In case of an asymmetric route" =>
 > "Otherwise, in case of an asymmetric route"

Done.

 >
 > Page 20, Sect. 7, the second paragraph: "is at least as large" as what?
 > As the sequence number in the RREQ-DIO message?

Done.

 >
 > Rather than / in addition to Appendix A, perhaps citing relevant
 > scientific papers may be informative?

We cite the following relevant papers.

-  Lifeng Sang and Anish Arora and Hongwei Zhang, "On Link Asymmetry and
    One-way Estimation in Wireless Sensor Networks", ACM Transactions on
    Sensor Networks, Volume 6 Issue 2 February 2010 Article No.: 12pp 1–25i
    https://doi.org/10.1145/1689239.1689242

-  Kannan Srinivasan, Prabal Dutta, Arsalan Tavakoli, Philip Levis,
    "An empirical study of low-power wireless", ACM Transactions on Sensor
    Networks, Volume 6 Issue 2 February 2010 Article No.: 16pp 1–49
    https://doi.org/10.1145/1689239.1689246

- Prasant Misra; Nadeem Ahmed; Sanjay Jha, "An empirical study of 
asymmetry in
   low-power wireless links",  IEEE Communications Magazine
   (Volume: 50, Issue: 7, July 2012)

Naturally Yours,
Charlie P.


============================ Original email follows ======================

On 2/6/2022 11:05 PM, Konrad Iwanicki wrote:
> Dear authors,
>
> I have the following remarks regarding the draft. (The comments are 
> based solely on the contents of the draft. I did not review the change 
> log nor any meeting proceedings.)
>
> # Major issues / questions:
>
> 1. For garbage-collecting RREQ- and RREP-DODAGs that are no longer 
> necessary, a timeout solution is used: the L field in the RRE(Q|P) 
> messages. Although this is not formulated explicitly in the draft, 
> from the format of the messages, I assume that the timeout is counted 
> locally and independently by each node, from the moment it joins the 
> corresponding DODAG. In particular, depending among others on the 
> network topology, the configuration of Trickle, and the underlying 
> link-layer, a node may start a timeout for a DODAG after another has 
> already left this DODAG. This is dangerous as it may lead to 
> situations in which information about a DODAG is never 
> garbage-collected because nodes that leave the DODAG may rejoin it 
> upon hearing information from other nodes that are still in the DODAG. 
> I would opt for an alternative solution or at least some poisoning- or 
> grace-period based approach. In addition, it would be nice to have in 
> the draft a potential risk analysis regarding the configuration 
> parameters of the solution.
>
> 2. What is the rationale behind deleting by TargNode the DIO ART 
> Option containing its address (and then taking address set 
> intersections when propagating the DIOs)? What problem do these 
> mechanisms aim to solve? A node can still receive DIOs along multiple 
> paths. It should be able to choose the "most desirable one". Deleting 
> the target address and using the intersection mechanism described in 
> Sect. 6.2.2. may actually preclude this behavior if the "most 
> desirable path" for a TargNode is not the one it obtains first. For 
> example, consider the following circular network:
>
>   A1 - OR - B1
>   |         |
>   A2        B2
>   |         |
>   T1 - T2 - B3
>
> with OR = OrigNode, T1 = TargNode1, T2 = TargNode2, and (A|B)* acting 
> as intermediate routers. Suppose that the path over nodes B* is the 
> most desirable one for both T1 and T2. Now, consider the following 
> scenario. T1 receives an RREQ-DIO first from A2 and joins the 
> RREQ-DODAG. It then propagates the DIO to T2 but with ART Option with 
> its own address (T1) removed. In effect T2 also joins the RREQ-DODAG, 
> remembering however that the last RREQ-DIO contained only T2. Now, T2 
> finally receives an RREQ-DIO from B3. It does not propagate to T1 this 
> path because: (1) it removes its own address from the DIO and (2) the 
> address of T1 is not included because of taking the intersection of 
> the address sets T2 received in the DIOs along the two paths. In 
> effect, T1 will never learn the most desirable path. Is this what is 
> expected to happen or am I missing something? Again, it is not clear 
> to me what the goal of the removal and intersection is. In the end, 
> original RPL creates routes from multiple targets (all nodes) to the 
> root, so why does this protocol require dynamically removing the targets?
>
> 3. A related concern applies to Sect. 6.2.6., more specifically, to 
> the second statement: "If, on the other hand, TargNode was already 
> associated with the RREQ-Instance, it takes no further action and does 
> not send an RREP-DIO." To me, it implies that TargNode replies with 
> RREP-DIO to the first RREQ that results in its joining the 
> corresponding RREQ-DODAG. In particular, if it learns about a better 
> path to OrigNode, it does not use this path instead of the first path 
> it joined. Again, am I missing something or is this intentional? If 
> so, it seems somewhat conflicting with the second paragraph of Sect. 
> 6.3, which allows the node to wait for RREP_WAIT_TIME before replying. 
> Trying to combine these two sections, my understanding would be that 
> TargNode sends an RREP to the best path that it is able to learn 
> within the RREP_WAIT_TIME. If this was the intention, then what is the 
> rationale behind setting the default RREP_WAIT_TIME to 0 for L = 0? 
> This would imply that for an RREQ-DODAG that is to be maintained 
> infinitely long, only the first path to OrigNode learned by TargNode 
> is considered. In general, why not introduce into the protocol 
> algorithms for TargNode to update its path when it learns a better 
> one? This would also require updating RREP propagation, which is again 
> done only for the first received message (per Sect. 6.4).
>
> 4. It is not entirely clear to me how Trickle timers govern 
> transmissions of multicast RREQ/RREP DIOs. In particular, when the 
> timers are reset? How is this policy influenced by the fact that, in 
> line with my previous comments, in principle a node reacts only the 
> first RREQ/RREP DIOs that cause its joining the corresponding DODAGs. 
> Perhaps a bit extended discussion of these issues could be provided in 
> Sect. 8.
>
> 5. There is also no discussion in the draft of a situation in which a 
> node has no resources to join a RREQ- or RREP-DODAG. While in the case 
> of RPL, this is arguably not that relevant, in the proposed protocol, 
> there may be many concurrent DODAGs, and hence it is intuitively more 
> likely that some nodes may lack resources to handle all DODAGs.
>
>
> # Smaller issues / nits:
>
> Page 4, definition of "AODV": add a space between "Routing" and 
> "[RFC3561]".
>
> Page 4, definition of "DODAG RREQ-Instance": "control message 
> transmission" (hard to parse) => "transmission of control messages"
>
> Page 4, definition of "DODAG RREP-Instance": the same as above
>
> Page 6, text ""RREQ-DIO message" means the DIO message from OrigNode 
> to TargNode" is confusing as DIO messages are link-local. Changing 
> this to ""RREQ-DIO message" means a DIO message from OrigNode toward 
> TargNode" may sound better. The same applies to the next statement.
>
> Page 8, definition of "L": "the time" => "time"
>
> Page 8, definition of "MaxRank" is confusing. The name would suggest 
> that this is the maximal allowed value, whereas the text implies that 
> this is the minimal disallowed value. Perhaps the name "MaxRank" could 
> be changed to something else, like "RankLimit".
>
> Page 8, "Other nodes MUST NOT join RREQ instance if its own Rank would 
> be" => "Any other node MUST NOT join..."
>
> Page 9, definition of "L": "The lifetime of the RREP-Instance MUST be 
> shorter than the lifetime of the RREQ-Instance to which it is paired. 
> What if the lifetime of the RREQ-Instance is infinite? In general, why 
> such a requirement?
>
> Page 14, the last paragraph, text starting from "It does this..." is 
> unclear to me. What happens in the end with MaxUseRank? (This is the 
> first and only paragraph where this symbol occurs.)
>
> Page 18, the last paragraph: term "shift" is somewhat misleading (to 
> me it describes bit shifts: right shift, left shift). Perhaps "offset" 
> or "delta" would be better.
>
> Page 18, the last paragraph: The text starting with "In RREP-DIO 
> option, the Shift field..." seems confusing. More specifically, it is 
> not clear to me what is shifted/offset: (1) does the receiving node 
> have to offset the RPLInstanceID in the RREP-DIO to obtain the 
> RPLInstanceId in the RREQ-DIO OR (2) is the RPLInstanceID in the 
> RREP-DIO equal to the RPLInstanceID in the RREQ-DIO but the receiving 
> node should offset the former so as to avoid conflicts? I guess it is 
> (1) but am not sure based on the text. In particular, what "original" 
> means there?
>
> Page 18, the last paragraph: "would prevent intermediate routers to 
> distinguish" => "would prevent intermediate routers from distinguishing".
>
> Page 20, Sect. 6.4.4., "Otherwise In case of an asymmetric route" => 
> "Otherwise, in case of an asymmetric route"
>
> Page 20, Sect. 7, the second paragraph: "is at least as large" as 
> what? As the sequence number in the RREQ-DIO message?
>
> Rather than / in addition to Appendix A, perhaps citing relevant 
> scientific papers may be informative?
>
>
> That seems all given the time I had. Hope that the review helps.
>
> Best,