Hi John and Stan,
I agree with you both on the separation of RIB etc.
However, for the RREP and ack discussion: when the RREP arrives at A, A
installs a valid route to TargAddr and can start forwarding regardless of
whether acks have been sent. I dont think there's a race condition
there...? The acks are only relevant for routes to OrigAddr. If the RREP
goes back to RREQ_Gen first, and then RREP_Acks go back toward TargAddr (at
the same time as data), all the intermediate nodes then set the route to
OrigAddr to a valid state (idle I think), one by one, towards TargAddr.
Potentially if data was received at TargAddr, and TargAddr sent data back
to OrigAddr before the RREP_Ack got back to RREP_Gen, then the route to
OrigAddr would still be Unconfirmed at RREP_GEN and we might initiate a
RREQ and buffer the data...but when the ACK catches up, the route to
OrigAddr becomes valid and the data would be forwarded. No route errors
would occur though, like in the hop by hop case.
Aside from the downsides of extra delay and extra control traffic, I think
it might be more correct to require the RREP to reach RREQ_Gen before acks
then get sent all the way back to RREP_Gen. Otherwise we risk adding routes
to OrigAddr prematurely, since a) the rest of the route might not be
bidirectional and b) if we start using the route to OrigAddr before
everyone further down the line has installed it, we will see errors as John
mentioned.
Regards,
Vicky.
On 13 Oct 2015 21:55, "John Dowdell" <john.dowdell486@xxxxxxxxx> wrote:
Hi all
I think this problem is in two parts.
1. Should AODVv2 perform its routing discovery calculations and
recording in a private workspace, away from the RIN and FIB, before the
route is declared valid and can be released to the RIB? I think it should.
2. Should RREP-Ack be performed on a hop by hop basis, or end to end?
Example: Router A is originating, routers B and C are intermediate, and
Router D is the destination. Hop by hop ack would mean D sends C an RREP,
then C sends D an RREP-Ack. End to end means RREP-Ack is not sent until the
RREP arrives back at A, then A sends B an RREP-Ack, B sends to C and so on.
The first is ok unless data is ready to be sent D to A, then there might be
a data plane and control plane race in the reverse direction relative to
the route request. The second is ok unless there is data to be sent A to D
(which we know there is, otherwise the route would not have been
requested), and then there could be a data plane and control plane race in
the forward direction. I think I've just talked myself into hop by hop
RREP-Ack.....
Regards
John
On Tuesday, 13 October 2015, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Gahhhh, just realised I didn't incorporate this idea about the separation
from the RIB. Should I do this and release a version 13?
Sorry all!
Vicky.
On Wed, Oct 7, 2015 at 8:09 PM, Ratliff, Stanley <sratliff@xxxxxxxxxxx>
wrote:
John,
Uhhhh, I don’t know about a verbatim lift; the copyright is listed as
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Since the authors are listed as well as the IETF trust, I think we
should stay away from a verbatim lift. But using it as a template is OK.
Regards,
Stan
*From:* aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:
aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *John Dowdell
*Sent:* Wednesday, October 07, 2015 3:03 PM
*To:* AODVv2 Discuss <aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:* [aodvv2-discuss] Re: Routing workspace
Stan, many thanks. The text is pretty good and I guess we can lift it
verbatim, acknowledging where we got it from. It might raise a few eyebrows
but it’s all IETF copyright text (just checked that).
The big issue I now want to discuss is what happens as the RREQ reaches
its destination, and the process of sending RREPs and RREP-Acks starts.
This stems from a discussion Vicky and I had one sunny morning in the
office a few months back.
I believe there is a choice. Ether we can send an RREP-Ack after every
hop, or wait until the RREP reaches the originating router until the
RREP-Ack is sent back along the same path.
In the first case, the route is built incrementally and becomes live in
each routers RIB building backwards from the destination B towards the
originating router A. I don’t think we’ve ever discussed this, but I guess
the route is built with bidirectionality, i.e. a route that signposts B
from A will also signpost A from B? So that’s ok since A is requesting to
send data to B, not the other way around. However if a computer hanging off
B wants to send to A while the route is being built, there is the
possibility that a race condition could exist between the data plane and
the control plane, in that the data plane will attempt to forward data
while the route is still incomplete. If the data plane wins, RERRs could be
generated since AODVv2 might receive some data to forward shortly before
the RREP is received, or otherwise it could spawn a whole new set of RREQs.
Either way up it looks messy.
In the second case, the route is built in AODVv2’s private workspace and
only released to the RIB when the RREP-Acks are received. However, how will
AODVv2 know where to send the RREP-Ack? Nearly got myself a gotcha there
but I think it’s ok because AODVv2 is using it’s private workspace to
direct AODVv2 control plane messages. Rather like section 7.5 of LOADng.
This is slower to build the route that the first case but it should be
safer.
Oh gosh, have we built LOADng? I know Adrian’s directive was to fill the
AODVv2 draft with text but I’m wondering if we are going to awaken the
LOADng crowd with this one ….. however, LOADng does use the hop-by-hop
RREP-Ack method (section 6.3 of LOADng), which I think is open to the race
condition. Phew.
Discussion very welcome.
Regards
John
On 7 Oct 2015, at 17:25, Ratliff, Stanley <sratliff@xxxxxxxxxxx> wrote:
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. J
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
*Sent: *06/10/2015 20:43
*To: *AODVv2 Discuss
*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> wrote:
Hi,
Am 23.07.2015 um 17:37 schrieb Charlie Perkins <
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>:
Finally - some feedback!! Some comments inline...:
On Thu, Jul 23, 2015 at 11:56 AM, Dearlove, Christopher (UK) <
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.
_____________________________________________________
_____________________________________________________
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.
_____________________________________________________
