Hello Tony (and Luc André),
Many thanks for your careful review. Please find our follow-up comments
interspersed below.
On 4/2/2023 5:11 PM, Luc André Burdet via Datatracker wrote:
Generally, introduction section would benefit from 1-2 figures showing the
flows of RREQ etc. with flags resulting for symmetric/assymetric case and
collisions/multiple downstream RREQ sends & such anomalous cases.
We made some more diagrams showing some message flows, but it seemed
more appropriate to put them in an appendix.
_Heavy_ readability suggestions:
* Terminology
** "The RPLInstanceID in the RREP message along with the Delta value
indicates the associated RREQ-InstanceID." is heavily cryptic and leaves one
guessing whether the Orig & Trg RPL Instance IDs are related somehow to
'pair' ? It becomes clear later but either explain in terminology or just
say that both InstanceIDs are matched by mechanism explained in "section
6.3.3" to correlate them (or define the term "pair" precisely in
terminology).
Yes, the point is to enable the two instance IDs to be associated. I
added the suggested cross-reference to section 6.3.3. I don't think a
new terminology item is needed for this.
* section 3: "the proper OF" "with 'D' == 0" is _heavily_ cryptic until one
-really- knows 6550 intimately. Expand the acronym, flag semantics
I modified the text as follows:
The 'D' bit of the
RPLInstanceID field is set to
0 to indicate that the source address of the IPv6
packet is the
DODAGID.
* "The route discovery process is initiated when an application at the OrigNode
has data to be transmitted to the TargNode, but does not have a route that
satisfies the Objective Function for the target of the application's data." How
is taht possible if e.g. a global grounded DAG that can reach the destination
is already in place which would be kind of default 6550 behavior?
The route from the global grounded DAG might not satisfy the needed OF
between OrigNode and TargNode as discoverable via AODV-RPL. For
example, AODV-RPL may often find a more direct route, or a route with
reduced cost that does not traverse the root node.
Readability suggestions:
* include RRPE and RREQ in terminology for easier reading. yes, it's in intro &
it's really ROLL but nevertheless, I had to go and search for it.
Done.
* "This reduces the cost to building only one DODAG." Not clear what that
means. I think it's "with that the node can build one DODAG for multiple
targets" ?
Yes, that's right. We've inserted the suggested clarification.
* "The upstream neighbor router that transmitted the received RREQ-DIO is
selected as the preferred parent." would benefit from clarifying that it's
parent only for this DAG
Done.
Robusntess/Correctness suggestions:
* 'H' flag is redundant as information (either vector is there or not and that
basically indicates H). This will lead to semantically unclear packets. In case
H is set but a vector is sent what to do? what is semantic of H not set and no
vector?
The H flag essentially signifies whether or not the address vector field
is present. If it is set incorrectly, the message fields will likely be
misinterpreted. I don't know of a straightforward way to detect whether
or not the H flag is set incorrectly.
* L: 2-bit unsigned integer defined as in RREQ option. The lifetime of the
RREP-Instance MUST be no greater than the lifetime of the RREQ-Instance to
which it is paired. and what if not?
We added language to the draft explaining that, otherwise, resources
(e.g., memory) that could be released will remain unavailable. Since
consuming extra resources might not be fatal, the "MUST" was reduced to
"SHOULD".
* Logic behind Intersection instaed of union in section 6.2.2 is a mystery. Why
not only take the newest RREQ based on sequence etc ... Is it because 2 routers
can receive 2 RREQ on all-AODV-RPL-nodes in different sequence and the result
should be same no matter the order?
When two or more RREQs are received with the same Orig SeqNo, they were
transmitted by OrigNode with the same destinations and OF. When an
intermediate node receives two RREQs with the same Orig SeqNo but
different lists of destinations, that means that some intermediate nodes
retransmitting the RREQs have already deleted themselves from the list
of destinations before they retransmitted the RREQ. We don't want to
re-insert those deleted nodes back into the list of destinations.
Also, it would be good to spell out how
long all those RREQs have to be kept by a node ? for duration of the DAG?
For any particular Orig SeqNo, only one RREQ-InstanceID is maintained.
The L field limits how long the RREQ-Instance can be maintained.
What
happens if different RREQs come in with different values for S bit? how is the
S-bit joined (maybe I missed it reading)
AODV-RPL does not specify how to use the S bit when selecting RREQ
information for the return route to OrigNode. It could be that the
symmetric route is not preferable because an asymmetric route would have
better Rank evaluation from the Objective Function.
* "stale sequence number" needs defintion earlier instead of popping up in
6.4.3 after being already used
Done.
* " In this case, the router MAY optionally associate". What does "associate"
mean here? Same as "pair"? or simply "it received it before and was in path"
New wording not using "associate":
"In other words, the router MAY optionally include the Address Vector of
the symmetric route back to OrigNode as part of the RREQ-Instance data."
* 6.3.3. is cryptic, it is unclear why the Targ cannot just send the delta and
still sends its own RPLInstanceID. Examples of collision/no collicion would go
a long way here
Suppose TargNode receives the RREQ with value of Orig_RPLInstanceID =
0x3A. If TargNode had already used the value of 0x3A for an unrelated
Targ_RPLInstanceID, then TargNode cannot use that same value in the RREP
to be transmitted back to OrigNode. It would have to pick another
RPLInstanceID and then supply the Delta value that allows OrigNode to
figure out which of its Orig_RPLInstanceIDs is associated with the
received RPLInstanceID from the RREP.
* Secton 7: a sentence is probably missing that a intermediate router MUST
generate a G-RREP and send it further upstream after processing a received
G-RREP
Done:
"An upstream intermediate router that receives such a G-RREP MUST
also generate a G-RREP and send it further upstream towards OrigNode."
Omissions:
* what about multicast? is it specifically excluded?
It is excluded (along with other schemes modifying the semantics of an
IP address, etc.). We could re-tool AODV-RPL for multicast but it would
take a bit of work. It would be a different protocol document with new
message formats. This has been done in several ways for AODV, and any
one of those methods could be adapted for AODV-RPL. Most likely the
same multicast group all-AODV-RPL-nodes could be used for disseminating
the new multicast messages.
We will watch to see if there is a desire for a multicast routing protocol.
Regards,
Charlie P.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
