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?
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)?
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
