Hello Stan,
That is a good example. Right now AODVv2 has a concept of router
clients. If the RREQ is DestOnly, then only the router for the
destination would respond.
If we allow Intermediate RREP, I would definitely say that the
intermediate router should respond. But, in both cases, the RREP
provides a route through the node that generates the RREP, which isn't
exactly the same as the route obtained from OSPF.
Another question has to do with regenerating the RREQ. It should only
go to neighbors that belong to LL-MANET-Routers, which may not include
all OSPF-learned destinations. I think we also have this covered.
With judicious use of the inclusion of router clients from OSPF-learned
destinations, we might even be able to resolve questions about the gateway.
But I still think we shouldn't go there right now.
Regards,
Charlie P.
On 6/4/2015 12:00 PM, Ratliff, Stanley wrote:
Charlie,
That’s just part of the picture. Another part is this: If AODVv2 router “A” is actively looking for a route, and AODVv2 router “B” sees the RREQ, **and** has a route to the destination that it (router “B”) obtained from OSPF – does router “B” respond? With the OSPF-provided route?
Regards,
Stan
*From:*aodvv2-discuss-bounce@xxxxxxxxxxxxx [mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Charlie Perkins
*Sent:* Thursday, June 04, 2015 2:44 PM
*To:* aodvv2-discuss@xxxxxxxxxxxxx
*Subject:* [aodvv2-discuss] Re: Section 6.5.2/Unconfirmed routes
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>
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] *On Behalf Of *Lotte
Steenbrink
*Sent:* Thursday, June 04, 2015 2:05 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: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
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.
_____________________________________________________
