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.
These are some notes on the optional feature of multicast RREP (Section
12.3 in Version 9a or Section 10.3 in Version 9b):
1. This extension could have implications for the msg_hop_limit field in
the RREP. It might not be appropriate to set it to the hopcount from the
RREQ. If we are looking at bidirectional links then its fine - the route
found for the RREP might be better than the path the RREQ took, but at
worst it will be the RREQ path in reverse. If links are not bidirectional
(and I suppose we dont need to address this at the current time) then the
hop limit should be MAX_HOPCOUNT.
2. Metrics will be learned in reverse. i.e. the target will learn the
hopcount of the path the RREQ took, which is cost from Orig to Targ, and
the originator will learn the hopcount of the path the RREP took which is
actually the cost from Targ to Orig.
3. How does this impact the bidirectionality check? Would routers on the
RREP path still do AckReq when the RREP is multicast? Intermediate nodes on
the RREQ path won't know if the links are bidirectional - does it matter if
links are bidirectional though, if the return path is different?
Comments welcome :-)
Kind regards,
Vicky.
