Hello Gabriel and Nandu:
I have recently reviewed draft-montenegro-lowpan-aodv-00.
Here are some questions and comments:
* DYMO would be replacing AODV in future. Are we working on
AODV lowpan because of Zigbee compatibility or because
availability of experimental RFC3561 ?
* The draft refers to *aodvbis*, but the aodvbis draft has expired.
Is there a plan for aodvbis draft to make progress for another RFC?
If that is not the case, then I am happy to see that this draft defines
the aodvbis format in this draft and go forward as 'lowpan-aodv' protocol.
Otherwise, we should follow either RFC3561 format or DYMO format.
* The lowpan-aodv draft requires only RREQ and RREP for control data.
How about RERR for propagating error messages back to the sender ?
AFAIK, the L2 ACK failure may detect a link failure in the intermediate
node during a data transfer, should not it send an error message back
to the sender(previous node) of the packet ?
Should the intermediate node do route repairing on behalf of the
sender node?
* Also, aodvbis or dymo appends intermediate node information at each
hop with the RREQ and RREP control packet. This increases the length
of the control packet unnecessarily. In IEEE802.15.4 network, these
additional bits are undesirable, as we know. It is a good idea that
lowpan-aodv draft recommends not to use additional path node information
on the RREQ and recommends APN-count to be zero in the RREP.
* The lowpan-aodv draft also needs to discuss Hostid size field values
for lowpan.
When are you planning to publish the next revision of this draft?
Thanks,
-Samita
_______________________________________________
6lowpan mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/6lowpan
