[manet] Re: A partial response to <Re: Review draft-perk ins-manet-aodvv2-05>

Hello Chris,

Recognizing that a route does not exist was solved by AODV 
implementations in various ways, which seemed quite straightforward to me.

Buffering packets during path discovery makes a lot of sense and should 
be part of any reactive protocol specification. This feature was also 
specified by AODV.

Regards,
Charlie P.

On 6/11/2025 3:45 PM, Christopher Dearlove wrote:
> Re OLSRv2 and AODVv2 implementability.
>
> There are various things that are reasonably straightforward in each 
> case, but I know from my former colleagues who interfaced my OLSRv2 
> code (owned by my former employer, not publicly available) to the 
> Linux IP stack that some required details were possible but not 
> trivial. I don’t know whether such solutions have been publicly 
> documented by others.
>
> AODVv2 requires additional interfaces that OLSRv2 doesn’t. In 
> particular it needs to recognise a routing table lookup failure, and 
> it needs to decide whether while waiting for an entry to be added 
> whether to discard packets (with one set of problems) or to queue 
> packets (with another set of problems).
>
> Where and how such a discussion is appropriate is another issue. By 
> not including such discussion in RFCs, the OLSRv2 RFCs are agnostic as 
> to what they are running over. I think that’s correct, but the 
> question even for OLSRv2 is whether that is sufficient. For AODVv2 
> that applies even more so.
>
> Note that the WG didn’t implement OLSRv2, but some members of it did, 
> more than once.
>
>> On 11 Jun 2025, at 09:09, Abdussalam Baryun 
>> <[email protected]> wrote:
>>
>>
>>
>> On Mon, May 12, 2025 at 3:43 PM Juliusz Chroboczek <[email protected]> wrote:
>>
>>     Hello Charlie,
>>
>>     > Prior to resubmission last year, I reviewed the comments I was
>>     able to
>>     > find about AODVv2, plus some I had received by private email. 
>>     All of
>>     > those comments were addressed, except for the observation that
>>     AODVv2
>>     > needed to have a publicly available implementation for
>>     evaluation.  And,
>>     > now, there is an NS-3 implementation being made ready for
>>     general release.
>>
>>     If I'm not mistaken, NS-3 is a discrete event simulator running in
>>     userspace.  It is not clear to me at all how the experience of an
>>     implementation in NS-3 carries over to implementations on real
>>     hardware.
>>
>>
>> usually all the internet protocols usually are done in simulation 
>> first, it is a design requirement to reduce cost. All engineers do 
>> simulation first, it is more effective and efficient. Even babel was 
>> done in simulation first, I don't know why you think it is very 
>> different.
>>
>>
>>     I think that AODV(v2) is a nice protocol, and I have learnt a lot
>>     from it
>>     when designing Babel.  However, one important property that I
>>     took into
>>     account when designing Babel was implementability.
>>
>>
>> Do you mean that AODVv2 is not implementable, please specify to help 
>> this WG to understand, but just saying it is not implementable will 
>> not help us understand to accept the draft or not.
>>
>>
>>     Charlie, could you please outline how you would envision an
>>     implementation
>>     of AODVv2 running on a general pupose OS such as Linux? 
>>
>>
>> it should be implemented as this WG implemented OLSRv2, should we 
>> think different, what do you think?
>>
>>     What would need
>>     to run in userspace, what would run in the kernel, and what would the
>>     user/kernel interface look like?
>>
>>
>> This question is not used to be asked nor answered within most 
>> RFCs/IETF, usually it is for the programmer/industry to implement.
>> I asked a similar question in the past for OLSRv2 while we were 
>> discussing its progress in this WG, and got the answer that I gave 
>> you now.
>>
>> Best wishes,
>>
>> AB
>> _______________________________________________
>> manet mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> manet mailing list [email protected]
> To unsubscribe send an email [email protected]

_______________________________________________
manet mailing list -- [email protected]
To unsubscribe send an email to [email protected]