Re: [Roll] draft-qasem-roll-rpl-load-balancing

["Qasem, Mamoun" <[e-mail]>]

Hi Michael

Thank you very much for your support and feedback.
To anyone who is interested for more details about findings, please check the published paper in 2016 IEEE Conference on Standards for Communications and Networking (CSCN):
https://doi.org/10.1109/CSCN.2016.7785168

Looking forward to be adopted.
Many thanks
Mamoun

--------------------
From: Michael Richardson <[e-mail]<mailto:[e-mail]>>
Date: Fri, Mar 31, 2017 at 12:36 AM
Subject: [Roll] draft-qasem-roll-rpl-load-balancing
To: [e-mail]<mailto:[e-mail]>



Three thoughts:

1) I think that this an interesting way to easily define a new metric
   ("number of children"), which could be used as part of tie-elimination.

   ** So, it's my thought that this is good work that should be adopted. **

2) It seems to me that on a non-broadcast interface (PPP IPsec tunnels, such as might
   be used in ANIMA for the ACP), that it would be reasonable for an
   implementation not to send a DIO out on the interface which it has chosen
   as it's parent.
   If that occurs, then the parent can't do it's counts correctly.
   But, in the ANIMA case, we are using storing mode, and we will use it with
   DAO-ACK, so we can count DAOs.

3) But, I then thought about other situations with multiple interfaces, and I
   realized that there is another case where there is propogation issues,
   and that is 6tisch.
   It 6tisch, it may well be that the parent is not listening on the slotchannel
   that the child uses to send it's DIOs, and so the parent won't hear.

   I'm not sufficiently familiar with the minimal schedule to know if this
   is commonly a problem, but it seems like a concern.


--
Michael Richardson <[e-mail]<mailto:[e-mail]>>, Sandelman Software Works
 -= IPv6 IoT consulting =-




_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll


This message and its attachment(s) are intended for the addressee(s) only and should not be read, copied, disclosed, forwarded or relied upon by any person other than the intended addressee(s) without the permission of the sender. If you are not the intended addressee you must not take any action based on this message and its attachment(s) nor must you copy or show them to anyone. Please respond to the sender and ensure that this message and its attachment(s) are deleted.

It is your responsibility to ensure that this message and its attachment(s) are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this message or its attachment(s), or for errors or omissions arising after it was sent. Email is not a secure medium. Emails entering Edinburgh Napier University's system are subject to routine monitoring and filtering by Edinburgh Napier University.

Edinburgh Napier University is a registered Scottish charity. Registration number SC018373