Hi Stan,
I assume the IAR can still forward RREQ and RREP. I think the text means it
would not respond on behalf of the straggler, i.e. create a RREP, but it
would still forward the RREQ as any other AODVv2 router would. The
straggler would then create a RREP, and the IAR would forward the RREP as
any other AODVv2 router would...
Does "not respond" imply that it would take no action if it receives a RREQ
for an address in the AODVv2 network? If so we should say "RREQs for
addresses inside the AODVv2 network are handled using the standard AODVv2
processes described in Section ..." What do you all think?
Also, after making the change, did you want me to post to MANET as version
11?
Regards,
Vicky.
On Wed, Jul 22, 2015 at 9:55 AM, Stan Ratliff <ratliffstan@xxxxxxxxx> wrote:
John,
I took this off-list & unicasted, because I'm not interested in stirring
the pot. But, I'm concerned about the proposed text;
The IAR MUST respond to RREQ on behalf of all Internet destinations,This means that the IAR can *never* be the neighbor that helps you
i.e., destinations not on the configured 191.0.2.0/24 subnet. The IAR
MUST be configured so that it does not respond to RREQ for addresses
within the AODVv2 manet (here, 191.0.2.0/24).
discover a route *within* the AODVv2 network - It's like an AODV instance
that says "Oh, you can get to the Internet through me, but to a node in the
MANET?!? What?!? I know NOTHING! I see NOTHING!" ;-) And, what if you get
into a mobility scenario where you have something like:
Bulk of AODVv2 net -------------- IAR ------------ One lone straggler
who turned left when he should've turned right
|
|
|
Internet
In that scenario, none of the "bulk" nodes can find the straggler, and the
straggler can't find anything other than the Internet. Or am I missing
something?
Regards,
Stan
