Subject: Re: [manet] #9: Reserved value for AODVv2 SeqNum -- is it necessary

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 24 Jun 2013 18:47:49 -0700

Hello folks,

This issue is trickier than most.  It turns out that specifying the 
operation
of intermediate RREP is easier if there is a reserved value for the AODVv2
Sequence Number field.  Other than making the code shorter by maybe
a dozen lines, and the inherent preferability of reducing the number of
special cases, I didn't see a strong push for deleting the specification for
the reserved value.

There are some other peripherally related discussion points on the
mailing list, but which were not keyed directly to issue #9.  I will
try to find them and post any new insights to the issue tracker. If there
aren't any objections, I think it would be expedient and appropriate to
keep the existing specification of the reserved SeqNum value (0).

If I understand the point below:
> It will be not necessary but may be used by router's processing checks,

I think it does not materially affect the outcome of the issue
resolution, but a more complete explanation would be interesting.

Regards,
Charlie P.

On 1/19/2013 1:27 PM, manet issue tracker wrote:
> #9: Reserved value for AODVv2 SeqNum -- is it necessary
>
>
> Comment (by [email-masked]):
>
>   Replying to [ticket:9 charliep@…]:
>   >
>   >
>   >  Whether or not to specify a reserved !SeqNum is not a trivial issue.
>   >  With recent revisions, it is now feasible to conduct a Route Discovery
>   >  cycle (RREQ / RREP) without need for indicating that a !SeqNum is
>   >  invalid, and there do not seem to be any other instances in the current
>   >  specification where a !SeqNum has to be reported as invalid.
>
>   It will be not necessary but may be used by router's processing checks,
>   >
>   >  If there is to be a reserved value for !SeqNum, it seems that 0 (zero)
>   >  is a good choice, so that rollover skips from 65535 to 1 bypassing the
>   >  reserved value of zero.
>   >
>
>   I agree
>

-- 
Regards,
Charlie P.