Hi all
Sorry coming very late to this most enormous thread. I’m not sure if Lotte’s
email below has got lost in he noise but this is a very valid point from a
discussion that has run and run over past months.
I believe we do need the table that AODVv2 keeps privately as its own working
area; when a route is properly discovered then AODVv2 must somehow make the
route live. Vicky and I whiteboarded this back in the summer and it became
clear that the RREPs and RREP-Acks all had to happen in a particular order
during the end-to-end construction of a route in order to prevent premature
data sending by the originator, and subsequent route collapse as RERRs came
rolling in as the data raced the completion of the route. Or at least that’s
how it seemed to us.
Regards
John
On 23 Jul 2015, at 17:15, Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>
wrote:
Hi,
Am 23.07.2015 um 17:37 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>>:
One point:
It has to be allowed to make conformant AODVv2 by modifying the IP route
table directly. In fact, this would be the preferred implementation for
many platforms (e.g., IoT) that need small footprints.
This may be my lack of experience talking, but I'd figured that with most IP
routing tables, it is not possible to add things like route state or sequence
number to the entries.
But I can add some perspective on the IoT aspect: When I initially
implemented AODVv2 for RIOT, we didn't have *any* other routing table– the
network stack would simply ask AODVv2 for the next hop, and AODVv2 would look
it up in its own table and answer (or start a route discovery). Now we have a
flashy new FIB, and the guy who implemented it and I discussed a lot about
possibilities for other routing tables to add their own attributes to FIB
entry (which would obsolete the need for a dedicated AODVv2 table)... We
decided not to do this in the end, so AODvv2 is still maintaining its own
table internally and updating the FIB when relevant changes occur.
I agree that it would be bad to make it a MUST, but adding an “If you have to
fill an outside routing table, do it on these occasions” could be done imo if
it is considered useful.
Regards,
Lotte
So, making requirements about when to update the IP route table to match
AODVv2's internal route table information is out of scope, and even worse
would be cause IP internal route table implementations to be out of spec.
Regards,
Charlie P.
On 7/23/2015 8:24 AM, Lotte Steenbrink wrote:
Hi Vicky,
you're incredible!
I've added some comments inline.
Regarding our 2 week deadline: I will be on holidays starting august 1st
and I will be shouted at severely if I try to do any work or IETF related
stuff, so I won't really be able to help from then on (for three weeks).
Am 23.07.2015 um 16:33 schrieb Victoria Mercieca <
<mailto:vmercieca0@xxxxxxxxx>vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>>:
Finally - some feedback!! Some comments inline...:
On Thu, Jul 23, 2015 at 11:56 AM, Dearlove, Christopher (UK) <
<mailto:chris.dearlove@xxxxxxxxxxxxxx>chris.dearlove@xxxxxxxxxxxxxx
<mailto:chris.dearlove@xxxxxxxxxxxxxx>> wrote:
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.)
So...currently it is: "Ad Hoc On-Demand Distance Vector (AODVv2) Routing"
Should it be "Ad Hoc On-Demand Distance Vector Version 2 (AODVv2) Routing"
or "Ad Hoc On-Demand Distance Vector (AODVv2) Routing Version 2"
or "Ad Hoc On-Demand Distance Vector Routing Version 2 (AODVv2)"
Sounds the best to me, intuitively.
or "Ad Hoc On-Demand Distance Vector Version 2 Routing (AODVv2)"
Section 1, what’s the difference between loop avoidance and loop freedom?
Loop freedom is the state of having no loops. Loop avoidance is how you
ensure that. I guess this bit :
AODVv2 compares route metrics in a way that ensures loop avoidance.
AODVv2 also uses sequence numbers to assure loop freedom, enabling
identification of stale routing information so that it can be
discarded.
can be reworded to:
To ensure loop freedom, AODVv2 uses sequence numbers to identify stale
routing information, and compares route metrics to determine if advertised
routes could form loops.
sound ok?
I think so.
Section 2 is missing IAR. (Haven’t checked this section in detail, just
noticed that.)
Have added this into the Terminology section:
"Internet AODVv2 Router
An AODVv2 router with an interface to the Internet."
Do we need to also mention the acronym, i.e.
IAR (Internet AODVv2 Router)
?
Throughout: inconsistency in using RFC 5444 and [RFC5444].
Changed to a reference throughout - will display as [RFC5444]. Except in
section headings and in algorithm names in the appendix.
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?
Changed to 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.
Any feedback on these would be helpful at some point, if anyone gets time
to go through it.
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.
bit about neighbors which cant confirm adjacenty MUST be marked as
blacklisted (changed to a MUST).
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.)
Anyone like to suggest text? I cant think of anything that explains this
nicely.
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.)
Fixed now, not in 11.
Section 5, para 2, use of “or” seems wrong.
removed reference to RFC6551 since this is in 12.3 anyway.
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.)
This is the loopfree section... well... if we have a newer seqnum, the
route is automatically seen as not forming a loop. so we dont check
loopfree... so if we look at a case when we do check loopfree, the seqnum
of the advertised route must have been the same as the seqnum of our
existing invalid route. If AdvRte has a worse metric than current Route,
we cant guarantee it's loop free and shouldnt use it. It doesnt matter if
our route is invalid... we could be installing a route which formed a
loop, now assuming its a valid route, and send traffic down that route,
only for it to go round and round.
I think it would make sense to send this explanation back to the mailing
list :)
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.
I think we're still being misunderstood here.
Maybe we should say "in that case, requesting acknowldegment of a RREP ...
is unnecessary".
It's not that we wouldnt send the RREP_Ack, it's that we wouldnt request
it.
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.
Anyone know what is meant by "ignoring incomplete"?
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?
changed to a 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.)
This cropped up in a previous discussion on this list...
Yes, I think as part of the discussion that ended in Multicast RREP. Do we
need to add additional text for this? Also, I'm not quite sure what he
means by “get the timing right”– if we add/modify a routing table and it is
Active or Idle, the IP table should be modified accordingly as well (i.e.
add route or extend its lifetime). When a route becomes Invalid, remove it
from the IP routing table immediately. Or am I missing something?
Regards,
Lotte
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.
change to say "equal or better"
Section 6.7.1 Active the do A or B at the least should indicate preference.
is this in regard to the "expunge or mark as invalid"? what is the
preference, when a timed route expires?
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.
changed to "any matching routes with metric values worse than this route"
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.)
changed to "contents" because this comment was made before.
Regards,
Vicky.
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 <tel:%2B44%20%280%291245%20242194> | E:
chris.dearlove@xxxxxxxxxxxxxx <mailto:chris.dearlove@xxxxxxxxxxxxxx>
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.
********************************************************************
_______________________________________________
manet mailing list
manet@xxxxxxxx <mailto:manet@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/manet
<https://www.ietf.org/mailman/listinfo/manet>
