John,
Ok, here’s a take on routing tables, RIB/FIB, etc… I’m positive this will
generate additional discussion.
- I think that what *should* be happening is that AODVv2 should
maintain its own set of routing information, and use that information to update
the RIB “when appropriate”.
- The FIB should be left alone, never mentioned, relegated to
obscurity. We know it’s there, we know what it’s good for, but we don’t have to
touch it, so we don’t.
For a good example of how to couch the operations/terminology, I went looking
for the LOADng spec, and found this one:
https://tools.ietf.org/html/draft-clausen-lln-loadng-13
Look at Section 4.3 (Information Base Overview) for a pretty good write-up of
the tables used internally by the protocol, and just when the ‘routing table’
(a.k.a the RIB) gets updated. Section 7.1 of that same document goes into a bit
more detail on the composition of the LOADng “private table”.
IMHO - *this is a model we should leverage to our advantage*. From what I
remember and understood on the underlying issue, Clausen was banging on us
because we talked about updating the route table (the RIB). As I interpreted
the issue, it was along the lines of “If you’re going to talk about updating
the RIB, you need to fully explain in order to keep from causing
interoperability issues.” Again, notice the text in section 4.3 of the LOADng
draft – it basically says “Use the internal table to update the routing table.”
This approach generalizes the problem, taking away the interoperability
concerns – or at least it *should*. It’s a case of “sometimes, less is more”.
By abstracting it at that level, we avoid having to get down into the weeds as
to the mechanics of updating the RIB – that’s not (or shouldn’t) be our
problem, because it might (actually, it will probably) be just a tad different
from platform to platform – and it’s *absolutely, positively* different when
considering, say, a Linux-based version of AODVv2 versus a Cisco IOS-based
version of AODVv2.
I hope that makes sense. If not, let’s see if we can keep this thread going,
and reach some consensus. But let’s use LOADng as a template – the strategy
there is, since that’s Clausen’s draft, he can’t whine too hard, because our
counter is “Well, that’s pretty much the way *you* documented it in LOADng”…
takes the wind right outta his sails. ☺
Regards,
Stan
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of John Dowdell
Sent: Wednesday, October 07, 2015 11:44 AM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Routing workspace
Reposting on a new thread to stop this getting buried again.
John
________________________________
From: John Dowdell<mailto:john.dowdell486@xxxxxxxxx>
Sent: 06/10/2015 20:43
To: AODVv2 Discuss<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
Subject: Re: [aodvv2-discuss] [manet] AODVv2 comments
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<mailto: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
<vmercieca0@xxxxxxxxx<mailto:vmercieca0@xxxxxxxxx>>:
Finally - some feedback!! Some comments inline...:
On Thu, Jul 23, 2015 at 11:56 AM, Dearlove, Christopher (UK)
<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.
[The entire original message is not included.]
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
