Hello Justin,
thank you very much for your thorough and helpful review. We've adopted most of
your editorial changes and are currently mulling over the larger ones.
Some questions & comments for clarification:
From 2. Terminology:
------------------------------------
Local Route
An entry in the Local Route Set. (Local Route Set should have an entry,
something simple and pointing to the section JWD)
(Later in the document LocalRoute is used pick one JWD)
LocalRoutes are not the same as the Local Route set, as they're actually
entries of the Set, which is explained in section 4.5. Local Route Set. Since
LocalRoute is used before its explanation (in the RERR (Route Error)
definition of section 2), I can see how this is confusing. If my co-authors
don't protest, I guess we can just eliminate that mention by changing "a valid
LocalRoute" to "a valid route". Would that resolve this issue?
From 3. Applicability Statement:
--------------------------------------------------
(This should go in the intro JWD)
Which paragraph(s) are you referring to here?
From 4.5. Local Route Set:
------------------------------------------
(I’m assuming this is here to hint at the possibility of a unified
router with multiple routing protocols playing nicely together JWD)
Yup. Should we be more explicit there?
(I noticed that Unconfirmed is the only state that uses Route Request
message instead of route message, is that intended? Can unconfirmed route
state only be reached through Route Request messages? JWD)
Yes. Until a route learned through a RREQ is validated by a RREP/RREP_Ack
exchange, it is marked as unconfirmed (so that it can't erroneously be used
until we know it is useful)
(this seems like an entry that would always be full 1s on a route
request if true that should be stated to make things more clear JWD)
I'm not sure I understand what you mean here, I'm assuming that prefixlength ==
address length with RREQs?
From 4.6. Multicast Route Message Table:
---------------------------------------------------------------
(would this ever be in a RREQ? If no then I suggest using words similar
to “if RteMsg is an RREP JWD)
It would. RREQs can include the last known sequence number associated with
TargSeqNum. see 7.1.1. RREQ Generation:
6. For TargSeqNum:
* If an Invalid route exists in the Local Route Set matching
TargAddr using longest prefix matching and has a valid
sequence number, set TargSeqNum := LocalRoute.SeqNum.
From 5. Metrics:
-----------------------
AODVv2 enables the use of multiple metric types. Each route
discovery attempt indicates the metric type which is requested for
the route. Only one metric type may be used in each route discovery
attempt. (Already said this no need to say it again. JWD)
I don't quite understand this one– with the exception of “Only one metric type
may be used in each route discovery attempt”, yes,
the rest of the information in this paragraph may be puzzled together using
bits and pieces spread across the document– but previous criticism
(also from me) has been that this is very confusing, tiresome and
error-prone... Or did I misunderstand your comment here?
From 6.1. Initialization:
-------------------------------
Until MAX_SEQNUM_LIFETIME after its sequence number is reset, the
router SHOULD NOT create RREQ or RREP messages.
(Just to be clear one MUST wait 5 mins before starting to request any
route without a persistent store of the seq num, yes? JWD)
Yes... That mini paragraph is a bit redundant & contradictory, isn't it? I've
taken it out and the "must" in "must wait for MAX_SEQNUM_LIFETIME before it
creates any messages" was changed to a MUST.
From 6.2. Next Hop Monitoring:
------------------------------------------
(I can’t see how the above would be helpful at all JWD)
I'm assuming that "the above" refers to the text you've deleted, not the
general idea of leveraging external mechanisms to monitor connectivity, correct?
From 6.6. Route Discovery, Retries and Buffering:
------------------------------------------------------------------
(is there some table that lists routes that are being waited on? JWD)
Currently not, we're reshuffling things in order to make it more clear how to
do all of that.
From 6.7. Processing Received Route Information
--------------------------------------------------------
(MAY not MUST? Why wouldn’t one update it according to section 6.7.2?
JWD)
No idea. This is a MUST now.
From 6.7.1. Evaluating Route Information:
--------------------------------------------------------
(does processing stop here? It seems like it hsould be that isn’t
stated. JWD)
It does, in both instances. Since the if statements following those paragraphs
wouldn't match, there are nor no further processing instructions for the
loop-causing AdvRte, essentially terminating the processing procedure. This
pattern is employed in different places across the document; if that's desired
by the WG I can add "Stop processing AdvRte" or something similar.
From 6.7.2. Applying Route Updates:
--------------------------------------------------
(we seem to be missing when the Route Information Base should be
updated based on the new Local Route Set. JWD)
4.5. Local Route Set says:
When the Local Route State is stored separately from the Routing
Information Base, routes are added to the Routing Information Base
when LocalRoute.State is valid (set to Active or Idle), and removed
from the Routing Information Base LocalRoute.State becomes Invalid.
To me, the connection to the RIB is more of an issue connected to the general
architecture of the Local Route Set rather than the nitty gritty of detailed
update instructions, so I think that section 4.5 is the right place for this
information...
From 6.9.1. Local Route State Changes:
------------------------------------------------------
(it’s not clear to me how the RERR’s are identified consider rewording
to make it more clear. JWD)
I'm not quite sure what' s unclear here– would something like
o If a Route Error (RERR) message reporting the route as broken is received,
either from LocalRoute.NextHop, or with PktSource set to a Router
Client address, LocalRoute.State MUST immediately be set to
Invalid.
improve things?
(Shouldn’t they also be removed from the Route Information Base? JWD)
No– Unconfirmed routes can't be used for forwarding, and therefore shouldn't be
in the RIB in the first place.
7.1.1. RREQ Generation:
----------------------------------
(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!)
The table in question is the Multicast Route Message Table and you're
absolutely right– that should be stated explicitly. We've done so now.
7.2.3. RREP Regeneration:
--------------------------------------
(This seems like a bad idea to do on the reverse path. It would be a
good way to attack a network Forward RREQ and drop all RREP. JWD)
Wouldn't this attack be possible no matter if we allow RREPs to be dropped or
not? What am I missing here?
7.4.2. RERR Reception:
---------------------------------
(it’s not clear to me what the point of this invalid route is. It
doesn’t get used and doesn’t remove any existing routes. JWD)
The point of that invalid route is to keep the Sequence Number. One point of
keeping Sequence Numbers is to avoid processing stale messages that might be
received after long queuing delays.
(How do we check? It’s not at all clear how this is done. JWD! )
The word "check" perhaps is misleading, as the check has already taken place a
few paragraphs above.
I've reworded the paragraph in question to:
3. If there are previously Active LocalRoutes that MUST be reported,
as identified in step 2.:
* Regenerate the RERR as detailed in Section 7.4.3.
, does that resolve the issue?
7.4.3. RERR Regeneration:
-------------------------------------
(it’s not clear how we know which localroutes need to be reported JWD!
again, missing reference here, I've changed that to
2. For each LocalRoute that needs to be reported as identified in
Section 7.4.1:
, is that better?
Kind regards,
Lotte Steenbrink
Am 02.03.2016 um 05:18 schrieb Justin Dean <bebemaster@xxxxxxxxx>:
I've completed my review of the draft 13 of AODVv2. Attached is my updated
with comments (marked JWD) and various inline fixes draft/review. I've also
included a diff to illustrate the inline fixes. I did not review the
security section. I did have a few major comments which are marked with JWD!
Justin
<draft-ietf-manet-aodvv2-13
(2).txt><draft-ietf-manet-aodvv2-13.diff>_______________________________________________
manet mailing list
manet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/manet
