[aodvv2-discuss] Re: Hangout in progress?

  • From: Victoria Mercieca <vmercieca0@xxxxxxxxx>
  • To: aodvv2-discuss@xxxxxxxxxxxxx
  • Date: Sun, 3 Apr 2016 15:55:24 +0100

Hi Lotte,

Comments in line (sorry for the format, I'm using my phone):

On 3 Apr 2016 09:31, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx>
wrote:


Hi vicky,

Am 03.04.2016 um 02:01 schrieb Victoria Mercieca <vmercieca0@xxxxxxxxx>:

Hey Lotte,

This looks great...one miniscule nitpick - in your new text for 6.2 I'd
make it clear that both those conditions should be satisfied, ie matching
ip address and interface. Maybe say "has no entry where both the following
conditions are met" or better words to that effect?



Good catch! Done. :)

Is LocalRoute.NextHopInterface used mainly for forwarding...? i.e. when
the route gets copied to RIB and used in FIB...does AODVv2 need to use it
again after it's saved in a route? Or...another thought... when we say for
RREP, and maybe in some cases RERR, that we send the response or
regenerated version to the next hop on the route to OrigAddr or PktSource,
is it relevant to say at this point that the response would be addressed to
that next hop, and sent via that next hop interface? (Bearing in mind to
use wording that shows AODVv2 doesn't do the sending but instructs RFC5444
that that's what should happen)?



Oh, I think that’s a good point. I’ve added

The RREP MUST be sent over the same interface on which the REEQ that
triggered it was received.

to the end of the RREP Generation section,

"RREQ that triggered it". Not sure if the typo just crept into the email or
if you copied and pasted from the draft.


The RREP MUST be sent over the same interface on which the previous RREP
was received.

to RREP regeneration,


RREP would be sent to the next hop toward OrigAddr,  so should be sent on
the interface shown on the route to OrigAddr? Which should match an entry
in the neighbor table with same next hop ip and interface? This probably
also matches the interface on which the corresponding RREQ was received.

It MUST be sent over the same interface on which the RREP that triggered
it was received.

to RREP_Ack Generation, changed RERR generation and RERR regeneration as
follows:

If the RERR is sent in response to an undeliverable IP packet or RREP
message, i.e., if PktSource is included, the RERR SHOULD be
sent unicast to the next hop on the route to PktSource. It MUST be sent
over the same interface on which the undeliverable IP packet was received.
If there is no route to PktSource, the RERR MUST be
multicast to LL-MANET-Routers. If the RERR is sent in response to a
broken link, i.e., PktSource is not included, the RERR is,
by default, multicast to LL-MANET-Routers.


… But shouldn’t the same apply to RREQs as well? Even if it is multicast,
the behaviour of different interfaces may vary?

However, I was thinking more along the lines of– since Next Hop
Monitoring influences the validity of routes, shouldn’t
LocalRoute.NextHopInterface be consulted when determining whether a route
is valid?


Erm... you lost me. But I think we now are in a situation where routes have
next hop IP and next hop interface, and we should also have a neighbor
table entry with the same 2 bits of info. So the route's next hop ip and
intf can identify a neighbour entry, which also includes neighbor state,
which relates to route validity. Sorry, I'm waffling a little because I'm
not sure what you meant.

Kind regards,
Vicky

Best regards,
Lotte

Kind regards,
Vicky :-)

On 2 Apr 2016 10:28, "Lotte Steenbrink" <lotte.steenbrink@xxxxxxxxxxxx>
wrote:

Hi all,

Am 04.03.2016 um 19:21 schrieb Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx>:

Hi all,
for those who couldn't attend, a quick summary of what we've talked
about (and what I remember, so please add stuff that's missing...):

* Lotte is currently writing up a response to Justin's review send to
[manet] which will contain some clarifying questions, comments & also
suggestions to improve things to check if that's what the WG had in mind
* Editorial pen has ben passed to Lotte
* we went through Justin's comments that were marked as JWD! since we
figured those were the urgent ones and decided:

(AODVv2_INTERFACES isn’t defined before now it should be. Also what
does this configuration consist of? Also is the list empty if there is
 only one interface? JWD!)
Charlie will propose some text


Regarding this one (all other JWD!s are resolved now, yay :) ):

(How does one know which outgoing interface is the neighbor associated
with?  This seems like a very LARGE missing piece of required information
JWD!)
That's a big one. I think we've decided to  add an
entry Neighbor.Interface to the neighbor table and add an instruction
to 6.3.  Neighbor Table Update that says:

   o  Neighbor.Interface := Interface on which the RREQ or RREP
message was received

(plus add checks for Neighbor.Interface being correct everywhere
Neighbor is used) ?
I'm guessing we'll also have to link this to AODVv2_INTERFACES once
we've defined that one properly.


I’ve made the following changes so far:

in 4.3.  Neighbor Table:
add

   Neighbor.Interface
      The interface on which the link to the neighbor was established.

in 6.2.  Next Hop Monitoring:

change from:

 When an RREQ or RREP is received from an IP address
   which does not already have an entry in the Neighbor Table, a new
   entry is created as described in Section 6.3.

to:

When an RREQ or RREP is received and the Neighbor
   Table has no entry where:

   o  Neighbor.IPAddress == IP address from which the RREQ or RREP was
      received

   o  Neighbor.Interface == Interface on which the RREQ or RREP was
      received.

   a new entry is created as described in Section 6.3.

in 6.3.  Neighbor Table Update:
add

   o  Neighbor.Interface := Interface on which the RREQ or RREP was
      received.  MUST equal Interface.Id of one of the entries in the
      InterfaceSet (see Section 4.1).

and

   If the message is one of the following:

   o  an RREP which answers a RREQ sent within RREQ_WAIT_TIME over the
      same interface as Neighbor.Interface

   o  an RREP_Ack which answers a RREP sent within RREP_Ack_SENT_TIMEOUT
      over the same interface as Neighbor.Interface


…But I’m wondering if that’s enough? LocalRoute.NextHopInterface is
never actually used, and it should be. But I can’t find the right section
where LocalRoute.NextHopInterface and Neighbor.Interfaceshould be „tied
together“… I’ll continue my search, but if anyone has a pointer that’d be
great! :)

Regards,
Lotte



(There wasn’t any text above and it’s not clear how this is enforced.
I have an idle route and an unconfirmed route, the unconfirmed route is
updated to confirmed, I now have two valid route entries and no way to
demote/decide or otherwise purge one of them but I’m not allowed to do
that.  Setting the worse and previously idle route to unconfirmed seems
wrong and broken. JWD!)
Another big one, Vicky said she thinks there is some text in the Draft
that actually solves this and said she'd look it up, in case that's not
enough I've written this down in an unsent e-mail:

Ouch again. Unless I oversaw something, the Neighbor Table updates
never actually "travel back" into the routing table, do they? I would've
expected section 6.3. to say something like

   When the link to the neighbor is determined to be

   bidirectional, the Neighbor Table entry is updated as follows:


   [...]


   for all routes in the Local Route Set with this neighbor as
LocalRoute.NextHop, the following changes must be applied:

   o  if LocalRoute.State := Unconfirmed, set LocalRoute.State := Idle


   o  if LocalRoute.State := Invalid, set LocalRoute.State := Idle
[<== Is this a good idea though?!]


and

   When a link to a neighbor is determined to be broken,


   o  the Neighbor Table entry SHOULD be removed.

   o  for all routes in the Local Route Set with this neighbor as
LocalRoute.NextHop, LocalRoute.State MUST be set to Invalid


... Would that resolve the issue? (also, why do we have neighbor
*tables* but local route *sets*? aslo, I'm thinking we should define what a
"broken route" is.)

(perhaps I’m missing a table or something but I don’t remember any
RREQ table or list being described which i can check if a RREQ has been
recently sent with associated timers. If there is such a table then it
should be mentioned here. If there isn’t aon there should be. JWD!)
Fix: add reference to multicast route message table

(What are we checking! What table or timer is there to check? JWD!)
Fix: add reference to multicast route message table: if
no RREP matching our RREP_Ack is found there, no actions are required (as
the RREQ was unsolicited and should thus be ignored).
Buuut, as I'm typing this, I'm wondering– some RREPs are unicast and
would thus not be in the Multicast table– is this a problem? I'm thinking
it wouldn't because neighbors whose bidirectionality is unconfirmed get
their RREPs via multicast, but then the document shouldn't say:

"and RREP messages may be multicast when the link to

   the next router is not known to be bidirectional.

"
in section 4.6, should it? I think we should change the "may" to
"will".

(How is this done?  There is no table with recently sent RERR messages
to check. There needs to be though. JWD!)
Fix: since RERR are always unicast, they're not in the multicast
table, so we need to track them separately.
Charlie will write some text for such a RERR table. Note that the
existence of this table (or not) is not an interop issue.

   3.  Check if there are unreachable addresses which MUST be reported
       in a regenerated RERR
(How do we check? It’s not at all clear how this is done. JWD!)
Fix: a few paragraphs earlier, the draft says:

       If any of the above are false, a matching LocalRoute MUST NOT be
       made Invalid and the unreachable address MUST NOT be advertised
       in a regenerated RERR.

We figured the word "Check" is a bit misleading here, so we'll change
that to "If there are UnreachableAddresses identified in step 2,..."

   4.  For each LocalRoute that needs to be reported:
(it’s not clear how we know which localroutes need to be reported JWD!)
Similar to the issue above: add "as identified in section 7.4.2."

Regards,
Lotte



Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 04-2016