Samita, 

>  When are you planning to publish the next revision of this draft?

Obviously, you have to refer a new version here;
http://www.ietf.org/internet-drafts/draft-daniel-6lowpan-load-adhoc-routing-01.txt
which is updating what you are refering...


Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
----- Original Message ----- 
From: "Samita Chakrabarti" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, September 10, 2005 7:02 AM
Subject: [6lowpan] lowpan-aodv draft comments


> 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. 
>      

>  
>  Thanks,
>  -Samita
> 
> 
> _______________________________________________
> 6lowpan mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/6lowpan
> 
> 

_______________________________________________
6lowpan mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/6lowpan

Reply via email to