Subject: [manet] AODVv2 comments

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 23 Jul 2015 10:56:38 +0000

Some comments from an incomplete review of -10 (-11 came too late, but I see few changes).

Why incomplete? Partly time, partly here's enough to be going on with. What's not reviewed? Pretty much all of the actual algorithmic part of the protocol. Not because I'm suggesting that doesn't need review, quite the contrary, but one thing at a time. Not yet ready for Last Call.

"Version 2" doesn't appear in the draft title. (Not sure why only just noticed that.)

Section 1, what's the difference between loop avoidance and loop freedom?

Section 2 is missing IAR. (Haven't checked this section in detail, just noticed that.)

Throughout: inconsistency in using RFC 5444 and [RFC5444].

Section 3. AODVv2 doesn't support some things that OLSRv2 was required to support, in particular using same address on multiple interfaces (with a limitation that made that practical) as some wanted unnumbered interfaces (Stan IIRC).

Section 3 para 4 says route requests that can't be confirmed bidirectional should be ignored. Why should and not must?

Throughout: Much inconsistency in use of SHOULD vs should and MUST vs must. (Former in normative sections, latter or avoid otherwise.) Haven't noticed for MAY/may but worth checking.

Section 4.2 last paragraph. I would have thought this was a MUST NOT.

Section 4.3 second paragraph should (SHOULD) or MUST? I would have thought latter, and I think some later text assumes latter. Also later in section.

Section 4.4 para 3 can probably should be a 2119 word.

Section 4.4 sequence numbers wrap, so at the least a comment that indicates greater/less is according to that should be included. (An algorithm that properly handles the 0 omission would help implementers.)

Section 4.5 Is this table conceptual like that in 4.6? (Later in section uses word comparable that wouldn't be my choice.)

Section 4.6 has a broken paragraph. (Could easily be fixed in -11, haven't checked.)

Section 5, para 2, use of "or" seems wrong.

Section 5.1. I don't like that non-hop-count metrics aren't described (as hop count really isn't good enough in reality) and that adding a new metric type means adding code. The latter is a design issue, so there is no right/wrong here.

Section 5.3. I don't understand why a stored invalid route can't be overwritten by a new higher metric route. (Sequence number, that I understand.)

Section 6.2 is where I think bidirectionality becomes MUST, so earlier SHOULDs may be wrong.

Section 6.2 states that if some other mechanism is present routes can be known to be bidirectional. That's OK (I think). But then to say that RREP_ACKs can be omitted is wrong, given that various places describe consequences of missing RREP_ACKs, without considering this case. I think anything other than always sending RREP_ACKs is not appropriate.

Section 6.3 para 3 is I think unsupportable, to say that it's outside AODVv2 who regenerates messages. This is essential for compatible interoperability.

Section 6.4 page 23 para 2 (ignoring incomplete). I can see "(albeit usually positive)" being challenged.

Section 6.4 page 23 para 3 why fixed buffer? And as this is supposed to be IP's job, why specify?

Section 6.4 page 23 para 4 using [RFC 3561] in this way as a SHOULD makes it a normative reference, which is a downref, and it's buried somewhere in that reference without an indication. Should be pulled out and included in this document.

Section 6.4 penultimate para last line, why SHOULD and not MUST?

Section 6.5.2 made me realise a major omission. This is all about AODVv2's tables. But at some point those need copying to IP's routing table (as additions/updates/removals) and that's not discussed, and it's not listed in Appendix A. Also all the text in the document uses the AODVv2 tables, which is fine when within AODVv2, but of course any IP packet unicast (I think multiple unicast is noted as an alternative to multicast - and there's a comment on future use of unicast) would use the IP table, so would need to get that timing right. (Futureproofing in the latter case, but the multiple unicast may need thought.)

Section 6.6 point 3, the equal case. I think it's obvious, but should say "equal or better". (If that's wrong, it's not obvious.) May occur in other places.

Section 6.7.1 Active the do A or B at the least should indicate preference.

Section 6.7.1 about using idle and active routes to forward packets, this is also where that is done by IP, so it should be about idle and active routes being in IP's table.

Section 6.7.1 there's a mention of inferior matching routes. Not sure what's meant.

Figures are described as message structure. They are message content. Structure is 5444. (As worded there's a sort of suggestion of an alternative structure, but this isn't that, as there's no indication how optional fields would be handled.)

Section 7.1.3, that situations where RREQs are not regenerated are not declared makes me very uneasy.

Section 12. I'm not sure it's up to this document to specify TBD numbers. I also know from experience that IANA won't be happy with this presentation. They need it spelled out in detail, add this entry to this table, and so on. Look at the various OLSRv2 documents for details (especially later ones). Already existing TLVs shouldn't be in the IANA section - this is instructions to IANA what to do. If needed here, put in another section. Also why allocate a new SEQ_NUM TLV, I think the existing sequence number TLV (the version named (COMPLETE) - I'd just say that once somewhere) will do.

Section 12.4, I'd add an unspecified value, along the RFC 7188 line.

Section 13, para 4, what's said is true, but it's not as simple as this makes it appear. (And there are issues of information leakage in other layers.)

Section 13, use of sequence number as timestamp is good. Should think about how fast 16 bits wraps and if that's an issue. (Not saying it is, just food for thought.)

Section 13, specifying TIMESTAMP data, suggest indicate algorithm number.

I think Section 13 means that RFC 7182 should be a normative reference.

Appendix A I think should be about two way interaction with IP, and is missing IP routing table update. It's also very underspecified. For example the ability to queue packets has requirements to add packet to queue, to flush queue. Is it IP's responsibility to release queue when a route appears?

Appendix D needs to have its normativeness indicated. Is the description in the main body (which as I note I haven't reviewed) complete and normative, and this is example? (That would handle if there's any mismatch.) Otherwise things get messy.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************