Hi Stan,
Am 04.06.2015 um 19:58 schrieb Ratliff, Stanley <sratliff@xxxxxxxxxxx>:
Nope. J Just searching for clarity.
That means that unconfirmed routes will have to be held within AODVv2 data
structures, and I’m perfectly OK with that.
Regards,
Stan
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf OfLotte Steenbrink
Sent: Thursday, June 04, 2015 1:56 PM
To: 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>:
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] On Behalf OfLotte Steenbrink
Sent: Thursday, June 04, 2015 12:37 PM
To: 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>:
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] On Behalf OfJohn 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> 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> 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 email
in error, please delete it and immediately notify the sender.
_____________________________________________________
