[aodvv2-discuss] Fwd: [manet] AODVv2 comments

  • From: Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Thu, 23 Jul 2015 14:15:55 +0200

FYI (in case [manet] is filtered more rigidly than this list on somebody's
phone...)

Anfang der weitergeleiteten Nachricht:

Von: "Dearlove, Christopher (UK)" <chris.dearlove@xxxxxxxxxxxxxx>
Betreff: [manet] AODVv2 comments
Datum: 23. Juli 2015 12:56:38 MESZ
An: "manet@xxxxxxxx" <manet@xxxxxxxx>

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: chris.dearlove@xxxxxxxxxxxxxx

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
Chelmsford, Essex CM2 8HN.
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.
********************************************************************

_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet

Other related posts:

  • » [aodvv2-discuss] Fwd: [manet] AODVv2 comments - Lotte Steenbrink