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

Hello Henning,

Beauty is in the eye of the beholder.  In AODV my favorite solutions fit 
perfectly with the design of ICMP and the meaning of the word 
"reactive". The same design would work for AODVv2. Perhaps the [manet] 
WG considers to disqualify any protocol development that depends on such 
real-time reaction.  At least part of that reaction should properly 
reside in the kernel.

I am not aware of the huge security risk, but if you could provide more 
details I would be interested to learn.  Maybe we could incorporate some 
discussion about it in Section 14 of the draft.

Regards,
Charlie P.


On 6/12/2025 1:41 AM, Henning Rogge wrote:
> Hi,
>
> I think the important difference between implementing the OS interface
> of OLSR (v1 or v2, doesn't matter) and AODV (v1 or v2, doesn't matter)
> is that implementing the first one is trivial... setting up routes. It
> doesn't matter if you execute a command to set up the routes or
> directly interact with the kernel via netlink, the problem can be
> looked up on the internet and solved within minutes/hours.
>
> AODV is different because of the 'route failure detection' part, I
> have yet to see ANYONE having implemented a good solution for this.
> The only thing I HAVE seen is some hack with a custom kernel module,
> which is quite hard to get right, often breaks with kernel updates and
> presents a huge security risk. I would not trust most people designing
> such a module.
>
> Because of this some advice on how to implement AODV is more relevant
> than the same for OLSR (or OSPF).
>
> Henning Rogge
>
> On Thu, Jun 12, 2025 at 12:46 AM Christopher Dearlove
> <[email protected]> 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 [email protected]
>>
>>
>> _______________________________________________
>> manet mailing list [email protected]
>> To unsubscribe send an email [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]