Review of draft-ietf-roll-aodv-rpl-13 by Pascal

[inesrob]

Source: https://mailarchive.ietf.org/arch/msg/roll/KT7mNfAgELuQ_JlzfMN5xc-6NGI/

Dear authors and all;

Please find my comments on draft-ietf-roll-aodv-rpl-13 below:

Bottom line is that we're not there yet. I believe a number of mechanism are either underspecified or broken as described, e.g., the way a source route is constructed does not seem to work for nodes with different interfaces up and down.

---

                                      " Consequently, for traffic

between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic)
data packets either have to traverse the root in non-storing mode, or
traverse a common ancestor in storing mode."

=> Suggest to add references to RFC 6687 for the route stretch and to RFC 9010 for the detailed impacts.

---

          The on-demand nature of AODV

route discovery is natural for the needs of peer-to-peer routing in
RPL-based LLNs.

=> because ? "natural" lacks substanciation. One could argue the exact same for projected DAO, and all the DetNet / RAW work would support it. I'd remove that sentence. Instead, it would be nice to qualify the properties of on demand that fits which needs so we can derive applicability.

I'd say that all RPL variations have in common that they avoid building optimized routes between every all pairs of nodes, to save constrained resources and control protocol exchanges. On-demand enables an optimization for specific pairs where a larger main RPL DODAG will allow stretched but any-to-any connectivity.

---

" AODV-RPL can be operated whether or not P2P-RPL or native RPL is running otherwise."

I do not believe that is generally true, please remove the text. MOP 4 in DIOs could create a confusion between the reactive methods and a P2P RPL implementation will not recognize the RREQ option and may process the DIO or enter an error state. But it does not matter. I'd indicate that if ever RPL, P2P RPL, and/or AODV RPL run between the same nodes (so unlikely!) then they operate as different RPL instances anyway (since " the OrigNode builds a local RPLInstance and a DODAG rooted at itself."). Instances do not mix, by definition.

---

" For many networks AODV-RPL could be a
replacement for RPL, since it can find better routes at very moderate
extra cost. Consequently, it is unlikely that RPL would be needed in
a network that is running AODV-RPL, even though it would be possible
to run both protocols at the same time."

=> "better" is unsubstanciated.

I suggest to remove that text altogether. I believe that it suffices to say what I pointed above, that RPL and AODV RPL must be operated in different instances, which is unavoidablme since they are running with different MOPs, so they just cannot interfere. Which one is used is a policy decision, out of scope.

---

"

DIO
DODAG Information Object
"

=> Remove, this is already defined in RFC 6550

---

"
Source routing
A mechanism by which the source supplies the complete route
towards the target node along with each data packet [RFC6550]
"

=> if it is "complete" then this is strict source routing.

---

"
OrigNode selects one of its IPv6 addresses and sets it in the DODAGID
field of the RREQ-DIO message.
"

=>The address scope must encompass the domain where the route is built. E.G, not link-local.

---

"
H
Set to one for a hop-by-hop route
"

=> In the RPL culture we call that Storing Mode (I did not choose that term!!!). Source route is Non-Storing Mode.
Ideally we'd align terminology. Alse, it should at least be indicated in the terminology and the introduction.

---

" L
2-bit unsigned integer determining the length of time that a node
is able to belong to the RREQ-Instance
"
length of time => duration?

Also, 256 s might be very short for energy scavenging devices.

Could that be based on the " Lifetime Unit " in https://www.rfc-editor.org/rfc/rfc6550.html#section-6.7.6 so deployments could use very different ranges?

---

"In Figure 4 and Figure 5, BR is the Border Router, O is
the OrigNode, "

=> This seems to indicate that there's a need for a main RPL instance. But the text clearly said it is not the case.
So maybe indicate that this is an example where you have connectivity to the outside (which is not needed) and a main RPL Instance rooted at the BR (which is not needed either).

---

" criteria used
when determining whether or not each link is symmetric. "

=> maybe mention DLEP ? No pressure

---

"
Figure 5:
"
=> The propagation of both DIOs appears to be along a sequence of nodes though it is really flooded in a Rank Diameter around O. I believe it is worth explaining. Also, what happens when the S flag arrives at T with both flavors?

---

"to multicast group all-RPL-nodes".

=> could we have a all-AODV-RPL-nodes group? The all-RPL-nodes is for normal DIOs.

---

"The address in the ART Option can be a unicast IPv6 address or a"

=> The Target Prefix / Address in the ART option ...

---

Section 6.2.1 is pseudo code with no indentation. This results in ambiguity. For instance,

"
The upstream neighbor router
that transmitted the received RREQ-DIO is selected as the preferred
parent.
"

This is true only in the case where the received DIO is the best.

---

Section 6.2.2 :
"
After determining that a received RREQ provides a usable route
"

Does that determination impact the operation of this section? What if S=0?

---

Section 6.2.3 :

"
then the router MUST build or update its upward route
entry towards OrigNode,
"

Even if S=0 ? Even if not the newest sequence? Even if RREQ not from preferred parent to orig?
Suggest to list all the checks first and then if OK the action. Here the last sentence is only one of the checks and appears too late to follow the logic.

---

Section 6.2.5 :

What is the interface up is not the interface down, and the addresses are different?
The result is that the address list is not reversible. In particular, in the case where S = 1?

---

Section 6.2.5 :

"
If the router is a TargNode and was already associated with the RREQ-
Instance, it takes no further action and does not send an RREP-DIO
"
In 6.3.1 it says
"
For a symmetric route, the RREP-DIO message is unicast to the next
hop according to the Address Vector (H=0) or the route entry (H=1);
"

This means that if an RREP-DIO was sent on a bad path received fast, it will not be updated when a better path shows?

---

Section 6.3.3 :

This all idea of delta is complicated. Why not just place in that field the RPL instance ID of the RREQ instance? It's also 6 bits since it is a local RPL Instance ID.

---

Section 6.4.1 :
"
The router that
transmitted the received RREP-DIO is selected as the preferred
parent. Afterwards, other RREP-DIO messages can be received.
"

What if more than one RREP-DIO are received?

---

Section 6.4.4 :
"
If H=0, the
intermediate router MUST include the address of the interface
receiving the RREP-DIO into the address vector.
"

Same as the other direction. The address on the receive interface of the RREQ-DIO may not be visible on the interface from which traffic to target is received. It would make sense to place the address of the previous hop from which the RREP-DIO is received.

---

Section 7

"
an Intermediate router that receives a RREQ-DIO
message MAY transmit a "Gratuitous" RREP-DIO message
"

How does it select the RPL Instance ID? I believe only the target can do that so only the target should send the RREP-DIO

---

Keep safe,

Pascal

[charliep51]

On 3/17/2022 7:56 AM, Pascal Thubert (pthubert) wrote:

Dear authors and all;

Please find my comments on draft-ietf-roll-aodv-rpl-13 below:

Bottom line is that we're not there yet. I believe a number of mechanism are either underspecified or broken as described, e.g., the way a source route is constructed does not seem to work for nodes with different interfaces up and down.

---

                                       " Consequently, for traffic
between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic)
data packets either have to traverse the root in non-storing mode, or
traverse a common ancestor in storing mode."

=> Suggest to add references to RFC 6687 for the route stretch and to RFC 9010 for the detailed impacts.

Will do. Thanks for the suggestion.

---

           The on-demand nature of AODV
route discovery is natural for the needs of peer-to-peer routing in
RPL-based LLNs.

=> because ? "natural" lacks substanciation. One could argue the exact same for projected DAO, and all the DetNet / RAW work would support it. I'd remove that sentence. Instead, it would be nice to qualify the properties of on demand that fits which needs so we can derive applicability.

I'd say that all RPL variations have in common that they avoid building optimized routes between every all pairs of nodes, to save constrained resources and control protocol exchanges. On-demand enables an optimization for specific pairs where a larger main RPL DODAG will allow stretched but any-to-any connectivity.

On demand is better when routes are needed but aren't yet established.
Peer-to-peer routing is better when shorter routes are desired and especially
when it is desired to avoid heavier traffic through a root or gateway node of
the network. This seems natural to me. However, some peer-to-peer routing
should be done proactively, and so the sentence needs work. Thanks for
pointing this out.

---

" AODV-RPL can be operated whether or not P2P-RPL or native RPL is running otherwise."

I do not believe that is generally true, please remove the text. MOP 4 in DIOs could create a confusion between the reactive methods and  a P2P RPL implementation will not recognize the RREQ option and may process the DIO or enter an error state.

From RFC 6550:

[A] As per 6.7.1 " RPL Control Message Option Generic Format" of RFC6550,

"When processing a RPL message containing an option for which the
Option Type value is not recognized by the receiver, the receiver
MUST silently ignore the unrecognized option and continue to process
the following option, correctly handling any remaining options in the
message."

The above clause causes DIO message to be processed by any other reactive
protocol (e.g., P2P-RPL) that uses MOP 4 even if it does not understand the
RREQ option. Since the DIO message is not dropped but the AODV option is not
processed, I don't know how to predict the behavior if more than one P2P
protocol with same MOP operate in the network.

In order to remove the possible ambiguity when other protocols are using the
same MOP, and as you suggest below, I agree that AODV-RPL should use a new multicast group.

---

" For many networks AODV-RPL could be a
replacement for RPL, since it can find better routes at very moderate
extra cost.  Consequently, it is unlikely that RPL would be needed in
a network that is running AODV-RPL, even though it would be possible
to run both protocols at the same time."

=> "better" is unsubstanciated.

Better because shorter paths, etc.

I suggest to remove that text altogether. I believe that it suffices to say what I pointed above, that RPL and AODV RPL must be operated in different instances, which is unavoidablme since they are running with different MOPs, so they just cannot interfere. Which one is used is a policy decision, out of scope.

Do you think there are times when RPL discovers better routes than AODV-RPL?

---

"

DIO
   DODAG Information Object

"

=> Remove, this is already defined in RFC 6550

How about adding "(as defined in RFC6550)"? There ought to be
something to help the reader.

---

"
Source routing
A mechanism by which the source supplies the complete route
towards the target node along with each data packet [RFC6550]
"

=> if it is "complete" then this is strict source routing.

Maybe complete isn't best. We can just say "supplies a vector of addresses".

---

"
OrigNode selects one of its IPv6 addresses and sets it in the DODAGID
field of the RREQ-DIO message.
"

=>The address scope must encompass the domain where the route is built. E.G, not link-local.

That is a good point, thanks!

---

"
H
Set to one for a hop-by-hop route
"

=> In the RPL culture we call that Storing Mode (I did not choose that term!!!). Source route is Non-Storing Mode.
Ideally we'd align terminology. Alse, it should at least be indicated in the terminology and the introduction.

O.K. A new Terminology item is a good idea.

---

" L
2-bit unsigned integer determining the length of time that a node
is able to belong to the RREQ-Instance
"
length of time => duration?

O.K.

Also, 256 s might be very short for energy scavenging devices.

Could that be based on the " Lifetime Unit " in https://www.rfc-editor.org/rfc/rfc6550.html#section-6.7.6 so deployments could use very different ranges?

That's a lot more bits. It seems like a pretty big change at this point of time during Last Call. We could instead define a new Option to override the L field value in the Option header. Would that suffice? Maybe it should be done later after the base document is published.

---

"In Figure 4 and Figure 5, BR is the Border Router, O is
the OrigNode, "

=> This seems to indicate that there's a need for a main RPL instance. But the text clearly said it is not the case.
So maybe indicate that this is an example where you have connectivity to the outside (which is not needed) and a main RPL Instance rooted at the BR (which is not needed either).

We could change it so that BR has a different name, or we could make it clear that the use of BR is for illustrative purposes only and not necessary to run AODV-RPL.

---

" criteria used
when determining whether or not each link is symmetric. "

=> maybe mention DLEP ? No pressure

The criteria used do not have to conform to any standardized protocol.

---

"
Figure 5:
"
=> The propagation of both DIOs appears to be along a sequence of nodes though it is really flooded in a Rank Diameter around O. I believe it is worth explaining. Also, what happens when the S flag arrives at T with both flavors?

The evaluation of the rank seems preferable for picking among several
possible routes, not the setting of the S bit.

---

"to multicast group all-RPL-nodes".

=> could we have a all-AODV-RPL-nodes group? The all-RPL-nodes is for normal DIOs.

Agreed.

---

"The address in the ART Option can be a unicast IPv6 address or a"

=> The Target Prefix / Address in the ART option ...

Will do.

---

Section 6.2.1 is pseudo code with no indentation.

This is the first time I can remember having such a paragraph described as pseudo code.

This results in ambiguity. For instance,

"
The upstream neighbor router
that transmitted the received RREQ-DIO is selected as the preferred
parent.
"

This is true only in the case where the received DIO is the best.

A previous sentence specifies "... the following steps are not processed."

Perhaps a new paragraph after that statement would clarify so that the intended meaning is more evident.

---

Section 6.2.2 :
"
After determining that a received RREQ provides a usable route
"

Does that determination impact the operation of this section? What if S=0?

If S=0, the determination of Target Node status and determination of a usable route to OrigNode is still the same.

---

Section 6.2.3 :

"
then the router MUST build or update its upward route
entry towards OrigNode,
"

Even if S=0 ? Even if not the newest sequence? Even if RREQ not from preferred parent to orig?
Suggest to list all the checks first and then if OK the action. Here the last sentence is only one of the checks and appears too late to follow the logic.

That would seem to duplicate specification text in previous sections. Usually
such duplication is a bad idea, because duplication of text leads to errors
when one of the duplicated texts is edited but the other is not.

Even for S=0, reception of the RREQ means advertises a route to OrigNode. If the RREQ is not from a preferred parent, it should not be propagated. If the RREQ is not the newest sequence it should not be propagated. These are all specified earlier.

There are too many things in the preceding sections of the document to repeat
them here.

---

Section 6.2.5 :

What if the interface up is not the interface down, and the addresses are
different? The result is that the address list is not reversible. In
particular, in the case where S = 1?

In this case, the route is not symmetric and S = 0.

Each radio interface/link and the associated address should be treated s an
independent intermediate router. The two routers have different links and
the rules for the link symmetry apply independently for each of these.

---

Section 6.2.5 :

"
If the router is a TargNode and was already associated with the RREQ-
Instance, it takes no further action and does not send an RREP-DIO
"
In 6.3.1 it says
"
For a symmetric route, the RREP-DIO message is unicast to the next
hop according to the Address Vector (H=0) or the route entry (H=1);
"

This means that if an RREP-DIO was sent on a bad path received fast, it will not be updated when a better path shows?

The RREP advertises a route to TargNode. If the TargNode already sent an RREP, and then receives a better RREQ, it does not have to re-send the RREP.

---

Section 6.3.3 :

This all idea of delta is complicated. Why not just place in that field the RPL instance ID of the RREQ instance? It's also 6 bits since it is a local RPL Instance ID.

Delta is needed to associate the RREQ_InstanceID to the RREP_InstanceID. It
is possible that TargNode might use OrigNode's choice of RPLInstanceID for
some other unrelated route discovery. It is even possible that OrigNode's
choice of RPLInstanceID was previously used by TargNode for a route discovery
for OrigNode with a different OF. Using Delta to effect the association is
a good technique which is very simple to manage.

---

Section 6.4.1 :
"
The router that
transmitted the received RREP-DIO is selected as the preferred
parent. Afterwards, other RREP-DIO messages can be received.
"

What if more than one RREP-DIO are received?

This just means that the receiving node is getting multiple advertisements for
routes to TargNode. In such a case the router might already be in the DODAG.
AODV-RPL does not specify any action to be taken in such cases.

---

Section 6.4.4 :
"
If H=0, the
intermediate router MUST include the address of the interface
receiving the RREP-DIO into the address vector.
"

Same as the other direction. The address on the receive interface of the RREQ-DIO may not be visible on the interface from which traffic to target is received. It would make sense to place the address of the previous hop from which the RREP-DIO is received.

If a node transmits a RREQ over an interface which is different than the
interface from which it was received, both interface addresses should be in
the address vector.

---

Section 7

"
an Intermediate router that receives a RREQ-DIO
message MAY transmit a "Gratuitous" RREP-DIO message
"

How does it select the RPL Instance ID? I believe only the target can do that so only the target should send the RREP-DIO

Regardless of TargNode's choice of RREP_InstanceID and Delta, an intermediate
node can unambiguously identify the DODAG by using RREQ_InstanceID in the
returned Gratuitous unicast RREP to OrigNode. Then, when the intermediate
node later receives TargNode's unicast RREP, the intermediate node will be
able to make the association between RREQ_InstanceID and RREP_InstanceID.

[charliep51]

I believe that these proposed resolutions for Pascal's comments are sufficient to allow issue #3 to be closed.

[svranand]

Reopened for further comments

[inesrob]

It seems to me that this comments are not properly addressed in v15. Please correct me if I am wrong:

1----------
"" For many networks AODV-RPL could be a
replacement for RPL, since it can find better routes at very moderate
extra cost. Consequently, it is unlikely that RPL would be needed in
a network that is running AODV-RPL, even though it would be possible
to run both protocols at the same time."

=> "better" is unsubstanciated.

I suggest to remove that text altogether. I believe that it suffices to say what I pointed above, that RPL and AODV RPL must be operated in different instances, which is unavoidablme since they are running with different MOPs, so they just cannot interfere. Which one is used is a policy decision, out of scope."

Pascal answer on June: "Yes. It's hard to qualify shortest or best in radios. Depends on what you care for, and things keep changing anyway.
When the "shortest" paths are busy and dropping packets (including RR), it might be that a reactive protocol finds a "longer path".
This is the sort of things that the reader should understand to position the usability of the protocol. It is distributed, autonomic, but provides no optimality guarantees. The best option for a demanding application is probably to max out the Rank Diameter that the RR probe can reach, to avoid using a path that is not usable by the application."

2-------------------------
"
Figure 5:
"
=> The propagation of both DIOs appears to be along a sequence of nodes though it is really flooded in a Rank Diameter around O. I believe it is worth explaining. Also, what happens when the S flag arrives at T with both flavors?

"
Figure 5:
"
=> The propagation of both DIOs appears to be along a sequence of
nodes though it is really flooded in a Rank Diameter around O. I believe
it is worth explaining. Also, what happens when the S flag arrives at T
with both flavors?

The evaluation of the rank seems preferable for picking among several
possible routes, not the setting of the S bit.

Good to clarify that I the text.

3------------------------------

      The on-demand nature of AODV

route discovery is natural for the needs of peer-to-peer routing in
RPL-based LLNs.

=> because ? "natural" lacks substanciation. One could argue the exact same for projected DAO, and all the DetNet / RAW work would support it. I'd remove that sentence. Instead, it would be nice to qualify the properties of on demand that fits which needs so we can derive applicability.

I'd say that all RPL variations have in common that they avoid building optimized routes between every all pairs of nodes, to save constrained resources and control protocol exchanges. On-demand enables an optimization for specific pairs where a larger main RPL DODAG will allow stretched but any-to-any connectivity.

Pascal answer on 29th June: "I'm sure you saw that I did not mention it for the sake of a chat but with the hope that you'd place such text as this exchange in the document 😊
This would certainly help a rpl-junior reader."

5--------------------------------------------------

---

Section 6.2.5 :
What if the interface up is not the interface down, and the addresses are
different? The result is that the address list is not reversible. In
particular, in the case where S = 1?

In this case, the route is not symmetric and S = 0.

Each radio interface/link and the associated address should be treated s an
independent intermediate router. The two routers have different links and
the rules for the link symmetry apply independently for each of these.

Pascal answer in June: Please add clarifying text in the spec.

[inesrob]

Replied from Charlie:

Hello Ines,

Please find some follow-up interspersed below.

On 12/3/2022 5:39 AM, Ines Robles wrote:
Hi Charlie,

Many thanks for addressing these topics.

Based on my understanding
"For many networks AODV-RPL could be a replacement for RPL, since it can find better routes at very moderate cost."
When you mention AODV-RPL could be a replacement for RPL, we need to specify in which context needs to be present in order to this to happen, it is not enough to say "for many networks"

To be more specific... networks in which nodes could beneficially use routes that are not constrained to traverse common ancestors.

We need to define what technical features define "better routes", i.e. how I know that route A is a better route than route B.

I may be missing something but I thought this was the purpose of the Rank function. The ranking function is pretty much the way that nodes determine which routes are "better" ... isn't it?

Also we need to define what "moderate cost" means
I don't have a precise answer for this. It could be replaced by "similar in cost to base RPL", but the exact relationship depends on many factors.
Pascal suggested deleting this sentence, which I think could be adequate. If you want to keep this sentence, please clarify the sentence integrating technical funcamentation to the claim
I don't have any analytical results using AODV-RPL to prove the claim. However, I have quite many years of experience with AODV which has similar traffic patterns for route discovery. I thought that would be sufficient. I could delete the sentence, but that would represent a loss of information for the reader. What would you think about the following replacement text:

"Experience with AODV[citation] suggests that AODV-RPL will often find routes with improved rank compared to routes constrained to traverse a common ancestor of the source and destination nodes."

2. I think what needs to be explained is the following case: "Also, what happens when the S flag arrives at T with both flavors?"
   Is the answer the following_ " The evaluation of the rank seems preferable for picking among several possible routes, not the setting of the S bit. " If so, it is added in the text?
   As above, I thought that the evaluation of the rank was the only basis for preferring one route to another. I am a bit surprised to find that this has to be reiterated in the text. Indeed, for all other possible criteria X, the rank is to be used in preference to X when evaluating the suitability of a route. Isn't that true?

Adding your suggested phrase does not make the text incorrect. It does, however, open the door to many other questions about whether the rank is to be used in preference to <the questioner's favorite criterion>. If it resolves the issue and gets the document published, I am OK to include it.

Related to this: " Should we also clarify whether nodes should use "common sense" instead of the Rank? " How you would define "node common sense"?

I didn't mean this to be taken seriously -- sorry about that.

3. Related to this one: "The on-demand nature of AODV"
   What about? " The on-demand property of AODV route discovery is useful for the needs of routing in RPL-based LLNs when routes are needed but aren't yet established "
   Sounds reasonable to me.

What about to add what Pascal mentioned " all RPL variations have in common that they avoid building optimized routes between every all pairs of nodes, to save constrained resources and control protocol exchanges. On-demand enables an optimization for specific pairs where a larger main RPL DODAG will allow stretched but any-to-any connectivity " What do you think?

I think this is going quite far afield and does not have much to do with AODV-RPL.

4. Related to the issue of "Section 6.2.5 ", I think it is addressed in the Introduction as you say. No action points needed.

Thanks!

Many thanks again Charlie for your hard work on this,

You are very welcome. I regret that sometimes I had long delays in responding.

Naturally Yours,
Charlie P.

[inesrob]

From Ines:
Many thanks Charlie, Many thanks Anand for your email as well, Happy New Year to all!!!

Please find my comments inline below

On Sat, Dec 10, 2022 at 3:11 AM Charles Perkins <charliep@lupinlodge.com> wrote:
Hello Ines,

Please find some follow-up interspersed below.

On 12/3/2022 5:39 AM, Ines Robles wrote:
Hi Charlie,

Many thanks for addressing these topics.

Based on my understanding
"For many networks AODV-RPL could be a replacement for RPL, since it can find better routes at very moderate cost."
When you mention AODV-RPL could be a replacement for RPL, we need to specify in which context needs to be present in order to this to happen, it is not enough to say "for many networks"

To be more specific... networks in which nodes could beneficially use routes that are not constrained to traverse common ancestors.

Maybe something like the following: "For networks in which nodes could beneficially use routes that are not constrained to traverse common ancestors, AODV-RPL could be used, since it can find Point-to-point routes that consume less resources than the routes that traverse common ancestors" That makes sense?

We need to define what technical features define "better routes", i.e. how I know that route A is a better route than route B.

I may be missing something but I thought this was the purpose of the Rank function. The ranking function is pretty much the way that nodes determine which routes are "better" ... isn't it?

From RFC6550: "....Function: The Rank is the expression of a relative position within a DODAG Version with regard to neighbors, and it is not necessarily a good indication or a proper expression of a distance or a path cost to the root... (Page 21)."
"...The Rank is not a path cost, although its value can be derived from and influenced by path metrics. (Page 20)"

Maybe using the sentence suggested above?

Also we need to define what "moderate cost" means
I don't have a precise answer for this. It could be replaced by "similar in cost to base RPL", but the exact relationship depends on many factors.

Then, something like: "similar in cost to base RPL, the real cost will depends on many factors such as (...add examples....)" What do you think?

Pascal suggested deleting this sentence, which I think could be adequate. If you want to keep this sentence, please clarify the sentence integrating technical funcamentation to the claim
I don't have any analytical results using AODV-RPL to prove the claim. However, I have quite many years of experience with AODV which has similar traffic patterns for route discovery. I thought that would be sufficient. I could delete the sentence, but that would represent a loss of information for the reader. What would you think about the following replacement text:

"Experience with AODV[citation] suggests that AODV-RPL will often find routes with improved rank compared to routes constrained to traverse a common ancestor of the source and destination nodes."

Thank you, the sentence is Ok for me

2. I think what needs to be explained is the following case: "Also, what happens when the S flag arrives at T with both flavors?"
   Is the answer the following_ " The evaluation of the rank seems preferable for picking among several possible routes, not the setting of the S bit. " If so, it is added in the text?
   As above, I thought that the evaluation of the rank was the only basis for preferring one route to another. I am a bit surprised to find that this has to be reiterated in the text. Indeed, for all other possible criteria X, the rank is to be used in preference to X when evaluating the suitability of a route. Isn't that true?

Adding your suggested phrase does not make the text incorrect. It does, however, open the door to many other questions about whether the rank is to be used in preference to <the questioner's favorite criterion>. If it resolves the issue and gets the document published, I am OK to include it.

We should aim to keep it simple, not include confusion for the reader. Apologies, I might not fully understand your comment
This issue was referring to Figure 5, when the RREQ-DIO message goes from O to T, thus, the comment was: "...The propagation of both DIOs appears to be along a sequence of nodes though it is really flooded in a Rank Diameter around O. I believe it is worth explaining. Also, what happens when the S flag arrives at T with both flavors?..." (I might be wrong in my understanding of the sentence)

Do you think it is really flooded in a Rank Diameter around 0?

Related to this, "what happens when the S flag arrives at T with both flavors?": This scenario is not possible? both flavors means that S=1 and S=0?

Related to this: " Should we also clarify whether nodes should use "common sense" instead of the Rank? " How you would define "node common sense"?

I didn't mean this to be taken seriously -- sorry about that.

Ok, no problem, thanks

3. Related to this one: "The on-demand nature of AODV"
   What about? " The on-demand property of AODV route discovery is useful for the needs of routing in RPL-based LLNs when routes are needed but aren't yet established "
   Sounds reasonable to me.

Great, thanks

What about to add what Pascal mentioned " all RPL variations have in common that they avoid building optimized routes between every all pairs of nodes, to save constrained resources and control protocol exchanges. On-demand enables an optimization for specific pairs where a larger main RPL DODAG will allow stretched but any-to-any connectivity " What do you think?

I think this is going quite far afield and does not have much to do with AODV-RPL.

Ok, thanks

4. Related to the issue of "Section 6.2.5 ", I think it is addressed in the Introduction as you say. No action points needed.

Thanks!

Many thanks again Charlie for your hard work on this,

You are very welcome. I regret that sometimes I had long delays in responding.

Many thanks again Charlie, apologizing for the delay, I think for some reason I missed your reply email during my trip.