Fantastic - I'll update the Acknowledgements.
There were some questions about implementations on MANET recently... I
wonder if they are aware of this work....
Vicky,
On Thu, Jan 21, 2016 at 9:22 AM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
FYI :)
Anfang der weitergeleiteten Nachricht:
*Von: *Behnaz yousefi <behyousefi@xxxxxxxxx>
*Betreff: **Aw: loop scenario*
*Datum: *20. Januar 2016 19:36:57 MEZ
*An: *Lotte Steenbrink <lsteen@xxxxxxxxxxxxxxxxxx>
*Antwort an: *Behnaz yousefi <behyousefi@xxxxxxxxx>
Dear Mr. Steenbrink,
Thank you for responding to my email. It means a great deal to us to know
that our findings were helpful and it motivates us to continue our work
more eagerly. We really appreciate your answers to our questions they were
very helpful, we would get back to you if we confronted any other ambiguity
while modeling the new version.
As I mentioned in my previous email, we were modeling the version 12 and
now we are going to switch to version 13 and check some properties such as
loop freedom and monotonic increase of sequence numbers.We would like to
know whether there is any specific property you want to be checked, if
there is such property please let us know. Please note that our current
framework abstracts from time so it is not possible to check timed
properties yet.
We would be honored to be mentioned in the Acknowledgments section,
thanks for your suggestion. My colleague’s names are as follows: Dr.
Fatemeh Ghassemi and Dr. Ramtin Khosravi.
Best regards,
Behnaz Yousefi
School of Electrical and Computer Engineering
University Of Tehran
Tehran ,Iran
On Tuesday, January 19, 2016 12:41 PM, Lotte Steenbrink <
lsteen@xxxxxxxxxxxxxxxxxx> wrote:
Dear Ms. Yousefi,
thank you for prompting us towards your research and findings. I'm sorry
we didn't get back to you sooner, christmas etc. delayed our discussion a
bit...
In response to your findings, we've changed 6.7.1. Evaluating Route
Information in version 13 of the draft, which was just published
(https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13) so that
LoopFree() is *always* considered before adding a new route, even if all
known routes to date are Unconfirmed. Thank you so much for bringing this
to our attention!
Regarding your other questions:
- What is going to happen to the other unconfirmed routes?
They would remain. We had thought they could be used in future, either
when the Ack fails to return from a sent RREP, or for other route
discovery attempts in future.
- Would the second best route be used?
In general, yes: Section 6.7.2. Applying Route Updates says at the end:
If this update to the Local Route Set results in multiple LocalRoutes
to the same address, the best LocalRoute will be Unconfirmed. In
order to improve the route used for forwarding, the router SHOULD try
to determine if the link to the next hop of that LocalRoute is
bidirectional, by using that LocalRoute to forward future RREPs and
request acknowledgements (see Section 7.2.1).
But with the new draft, the second best would be the first best, since the
faulty route shouldn't be added anymore.
- Whether an “rerr” message is generated or an “rerr” message is
generated only when all unconfirmed routes become invalid?
The RERR is only generated if an Active route is lost. Idle routes may be
included in a RERR at this point, but Unconfirmed routes will never be
advertised as being lost.
Does this help? (In case you have any suggestions which/where
clarifications are needed in the Draft, they're greatly appreciated)
Additionally, we'd like to add you to the Acknowledgments section of the
next AODVv2 Draft. Are you okay with this, and are there any of your
colleagues who you think should be named also?
With kind regards,
Lotte Steenbrink (on behalf of the AODVv2 author team)
