Hi all,
While going through the draft I've come up with a load of questions and
notes. Addressing these will make the draft more complete and resolve some
of the ambiguity which might affect an implementation.
I'm going to divide these into a number of emails so that it should be
easier to follow each discussion.
This email contains questions about adjacency monitoring (Section 6.2 in
Version 9a and in Version 9b):
1. Should we explain why we need to monitor adjacency, i.e. what goes
wrong if we don't?
2. RREP_Ack and RREP are both proof of bidirectional connectivity. RREP
because we must have sent a RREQ that way for a RREP to come back. These
should both get a router taken off the blacklist. RERR and RREQ are not
proof of bidirectional connectivity so these shouldn't get processed if
received from a blacklisted router. There would be no point in processing a
RERR because it should not be the next hop for any of our routes, and
therefore we wont need to regenerate it either. We shouldn't process a RREQ
because the route to OrigAddr is unusable, and therefore we shouldn't
regenerate it either. I've put this in the draft already.
3. By blacklisting, we know which routers we should ignore, but we dont
keep a record of routers that we know have bidirectional connectivity. How
do we know if we need to send the AckReq? Should we also have a list for
routers we know we have bidirectional connectivity to (i.e. they already
sent a RREP_Ack, or other signals in this section)? Then we can decide if
we need to use the AckReq in the RREP. We could actually incorporate the
blacklist into this. e.g. a "Neighbor List" where Router A is a neighbor,
but currently blacklisted, with a certain associated remove time. Router B
is a neighbor, with confirmed bidirectional connectivity, Router C is a
neighbor with unconfirmed bidirectional connectivity so we should
use AckReq. List entries would have Address, State (Blacklisted, Confirmed,
Unknown), BlacklistRemoveTime. Perhaps we'd want to enforce AckReq every so
often to verify the neighbor is still bidirectional - there might be a
timeout so the state of a confirmed router goes back to unknown, or a
LastVerified timestamp?
4. If a link is determined to be non-bidirectional due to no RREP_Ack,
we should also delete the route to OrigAddr from the RREP. We know the link
from next router to us is OK because we received a RteMsg with route to
OrigAddr from that router previously, but the link is not available in the
other direction (towards OrigAddr). Since we previously advertised a route
to OrigAddr by forwarding that RREQ, every router between us and TargAddr
thinks we have a route to OrigAddr, so should we send a RERR? Or wait, and
only send a RERR if anyone tries to use our route to OrigAddr?
5. Should there be any retries on RREP if the Ack isn't received?
6. If we dont get the RREP_Ack, the next hop doesn't learn the route to
TargAddr, therefore the originator doesn't either. Originator will time out
and resend the RREQ. Should we explain that?
7. Further to point 6, If the new RREQ follows the same path, and the
same router forwards it to us, we will ignore it because that router is now
on the blacklist. If the RREQ comes to us from another router, will it have
a newer SeqNum? Otherwise we'll think it was redundant. Or... do we remove
entries from the RteMsg table if they are from blacklisted routers? We
don't actually save enough information to work out which ones came from the
neighbor we have blacklisted.
8. What do we mean by "route timeout" in the list in this section?
9. Should we use the term "adjacent" more strictly throughout the
document to refer to bidirectional connectivity?
10. Should we keep a list of recent RREPs sent with the AckReq inside,
so that we can verify that when a RREP_Ack is received, it is actually
expected? Otherwise a router could erroneously send an unsolicited RREP_Ack
to remove itself from a blacklist. Without being sure that we previously
sent a message in the opposite direction on this link, we cant be sure the
link is bidirectional. Similarly for RREP - if a router sent an unexpected
RREP (i.e. we didnt forward the corresponding RREQ) we shouldn't assume
this is proof of bidirectional connectivity. Should we keep a list of
RREQ's forwarded to avoid this?
Comments welcome :-)
Kind regards,
Vicky.
