Hello folks,
It helps to stand back and look at the larger picture.
AODVv2 does route discovery when it needs a route. If the router has a
route, then AODVv2 does not need to do route discovery.
We have put some conditions on when routes actually become available,
but once a route is available it should be available for use.
Regards,
Charlie P.
On 6/4/2015 11:10 AM, Ratliff, Stanley wrote:
Lotte,
Hmmm…. let me go back and read the draft again before I expound further.
The short answer is that I’m not sure that introducing another route table that’s AODVv2-specific is such a good idea.
That also brings me to ask about everyone’s understanding on route redistribution – AODVv2 using, or exporting, routes obtained from, say, OSPF running on the same router. That starts us down the path of the “gateway operation” that Justin has mentioned as a source of concern.
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Lotte Steenbrink
*Sent:* Thursday, June 04, 2015 2:05 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Re: Section 6.5.2/Unconfirmed routes
Hi Stan,
Am 04.06.2015 um 19:58 schrieb Ratliff, Stanley <sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>>:
Nope.JJust searching for clarity.
That means that unconfirmed routes will have to be held within
AODVv2 data structures, and I’m perfectly OK with that.
Great! I'm just wondering if we had/uncovered a misunderstanding in this thread... I was (/am) operating under the assumption that the route table described in the Draft is not *the* routing table used and filled by other protocols and parts of a network stack too, but rather a supplementary table which is then used to fill the central routing table. My base for this assumption was that the AODVv2 route table has more and other fields than the routing table I knew from Linux, and that most of those fields were relevant to AODVv2 only.
Is that assumption correct? Because in this thread, the distinction didn't seem so clear to me, and a) I don't want to make a fundamental mistake and b) I'm wondering if there's anything we should make more clear or if it's just me getting confused.
Regards,
Lotte
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx]*On Behalf Of*Lotte
Steenbrink
*Sent:*Thursday, June 04, 2015 1:56 PM
*To:*aodvv2-discuss@xxxxxxxxxxxxx
<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:*[aodvv2-discuss] Re: Section 6.5.2/Unconfirmed routes
Hi Stan,
Am 04.06.2015 um 19:07 schrieb Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>>:
Lotte,
I’m not really on-board with the notion that AODVv2 would keep
its own private RIB… but then, I’m used to a common RIB
updated by BGP, OSPF, RIP, and (yes) EIGRP, with conflicts
resolved by “administrative distance” values.
FWIW, I think this discussion boils down to “When does AODVv2
commit a route to the RIB?” Are you saying that unconfirmed
routes should be withheld from the RIB, until they are confirmed?
Yup. Is that a bad idea?
Regards,
Lotte
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx]*On
Behalf Of*Lotte Steenbrink
*Sent:*Thursday, June 04, 2015 12:37 PM
*To:*aodvv2-discuss@xxxxxxxxxxxxx
<mailto:aodvv2-discuss@xxxxxxxxxxxxx>
*Subject:*[aodvv2-discuss] Re: Section 6.5.2/Unconfirmed routes
Hi all,
Am 04.06.2015 um 17:53 schrieb Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx
<mailto:charles.perkins@xxxxxxxxxxxxx>>:
Hello folks,
I agree with Stan about not introducing the FIB into AODVv2.
Of course, that was just a not very well thought-out comment
on the side.... Sorry about that. What I was just trying to
say was that, since AODVv2's routing table is to be kept
internally anyway (or is this a huge RIOT-inflicted error in
my thinking?), I think we could keep the unconfirmed routes in
there and don't have to define yet another table...
Regards,
Lotte
Regards,
Charlie P.
On 6/4/2015 6:53 AM, Ratliff, Stanley wrote:
John,
You are correct in that there are two tables. In
classic routing, the first is the Routing Information
Base, or RIB. Protocols typically update the RIB as
conditions warrant (e.g., as routes are created or are
broken).
At least in one implementation that I’ve worked with
;-), the FIB is “shadowed” – that is, there is
software watching for changes in the RIB, and those
changes are then propagated to the FIB. While the RIB
is used for Layer 3 and above, the FIB is optimized
for Layter 2 forwarding. In AODVv2, as in any routing
protocol spec, my personal opinion is that we should
avoid referencing the FIB if possible.
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx
<mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx>[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx]*On
Behalf Of*John Dowdell
*Sent:*Thursday, June 04, 2015 9:06 AM
*To:*AODVv2 Discuss
*Subject:*[aodvv2-discuss] Re: Section
6.5.2/Unconfirmed routes
Hi both
So just to be a little more explicit on terminology
and usage here, I believe we are discussing two
tables; one is the “scratchpad” for AODVv2, and the
second is the live routing table, used for forwarding
user traffic. Apologies I am not sure about correct
terminology but I believe the second is called the
Forwarding Information Base (FIB), and live routes are
exported to the FIB from the scratchpad. Please do
correct my naming.
I also believe that routes in the scratchpad can be
(based on the below) be Unconfirmed (as in, under
construction), or Confirmed (as in, the route is fully
constructed but may or may not be exported to the FIB).
I further believe that even if a route is withdrawn
from the FIB, but still has a status of Confirmed, it
should not be expunged from the scratchpad but should
be held in reserve in case the route that has been
exported becomes faulty.
Regards
John
On 3 Jun 2015, at 12:01, Victoria Mercieca
<vmercieca0@xxxxxxxxx
<mailto:vmercieca0@xxxxxxxxx>> wrote:
Hi Lotte,
You are right, it would be better to explicitly
define it, and we should incorporate this text.
Kind regards,
Vicky.
On Wed, Jun 3, 2015 at 9:39 AM, Lotte Steenbrink
<lotte.steenbrink@xxxxxxxxxxxx
<mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Hi all,
while implementing Unconfirmed routes, I had a
bit of a hang up with section 6.5.2., which says:
If the RteMsg containing AdvRte is a RREQ,
the route is not yet
confirmed. It should be stored, so that a
corresponding RREP can be
sent, but should not be used to forward
data. If there is already a
matching route, this new route should be
saved as an additional route
using the process below, and can replace
the original route when
adjacency with the next hop is confirmed.
Because there is no mention of the word
Unconfirmed, I first missed this part while
searching through the Draft for cues how to
implement Unconfirmed routes...
I'm wondering, would it make sense to
explicitly write down the process hinted at
above? After all, it is a routing table ,not a
FIB... It could have several entries for one
route. So the process could be something like
this:
- if no other route exists and the RteMsg is a
RREQ, add the entry and set it to Unconfirmed.
- if another route exists and the RteMsg is a
RREQ, add another entry and set it to Unconfirmed
- if other route(s) exist and the RteMsg is a
RREP:
- if the only other route is Unconfirmed, set
it to confirmed.
- if there is an Active/Idle/Invalid route and
an Unconfirmed route, set the Unconfirmed
route and expunge the old Active/Idle/Invalid
route.
(maybe the third point plus subpoints could
also be woven into section 6.5.1.)
Regards,
Lotte
_____________________________________________________
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.
_____________________________________________________
_____________________________________________________
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
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.
_____________________________________________________
