Hi Charlie and all
On 3 Mar 2016, at 21:12, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>Agree with that
wrote:
The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing
protocol (formerly named DYMO) enables on-demand, multihop unicast
routing among AODVv2 routers in mobile ad hoc networks (MANETs)
[RFC2501].
(We jumped right in here would prefer some intro to AODV and how AODVv2 is
derived from that work. JWD)
For intro to AODV, we could wordsmith the introduction to RFC 3561.
Significant differences between AODV and AODVv2:
- RFC 5444
- Security mechanisms from RFC 718* and upcoming
- Intermediate node operation separated out
- Extended and improved definitions for sequence number timeout, route
timeouts
- Improved verification for link bidirectionally
(Wireless properties of the network is not mentioned at all and this is
quite important as I’m pretty sure AODVv2 for used in a wired network
would be a bad idea JWD)
This is not true. AODV could very well be used in a wired network. More
examples later, but already IoT comes to mind. A generic scenario would be
one in which there is a cost to maintaining a link, and there are many more
links available than communication channels needed at any one time.
attached to external networks, as discussed in Section 9. (some mention of
limitations of the provided approach is required. No default gateways,
drawbacks/overhead of using AODVv2 network to connect to the Internet using
provided approach JWD)
I'm fine with no default gateways right now -- we can design this later and
it's nontrivial.
For the drawbacks/overhead -- I'll have to ask because I don't know what is
being suggested.
(There is an issue with trust being limited to single hops and no way to
verify information more than one hop away JWD)
Maybe the E2E draft will help with this.
(this should be disallowed as it can form non valid routes with
uni-directional links JWD)
I'll post to the list about using the MAC addresses.
(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!)
Something went wrong here. There is a dangling reference in section 11.3. I
think it's best to simply define AODVv2_INTERFACES. It could be as simple as
the list of interfaces over which AODVv2 control messages may be sent. It
has to be clear that we're not sending these control messages out into the
Internet. The wording in section 4.1 has to be adjusted to more clearly
allow AODVv2_INTERFACES to contain a single interface.
router at any one time. (do things break when a Router Client is served by
more than one AODVv2 Router? My guess is yes and therefore SHOULD be a
MUST. JWD)
Basically, this exhibits a difference of opinion about the definition of
SHOULD versus MUST. SHOULD means "do it" unless you have a good reason not
to do it. In this case, a good reason would have to guarantee correct
handling of the sequence number for the client. I wish we could make more
room for future designers but even so I'm not going to fuss about this.
(How does one know which outgoing interface is the neighbor associated with?
This seems like a very LARGE missing piece of required information JWD!)
I'm O.K. with putting in information about the outgoing interface. I don't
know just where we would have to use it, though.
If you want to expand the Blacklist to allow multiple entries for the same
neighbor, then you might be able to allow connectivity by some interfaces and
not by others -- for instance only responding to RREQs over certain
interfaces and not others. This is related to the MIA discussion I sent out
earlier today.
(I’m assuming this is here to hint at the possibility of a unified router
with multiple routing protocols playing nicely together JWD)
I don't know what to make of this. Should we eliminate the term Route Set?
I don't see why the suggested hint would be inferred.
(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)
As far as I know the answer is yes. Does that need to be said?
(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!)
Don't we say that an idle route can be purged at any time?
(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)
The RREQ should only be requesting a route for a unicast address. Specifying
subnet RREQ is not part of the current draft.
I don't think that TargPrefixLen should appear at all in RREQ.
(would this ever be in a RREQ? If no then I suggest using words similar to
“if RteMsg is an RREP JWD)
If TargSeqNum appears in RREQ, then RREQ_Gen is asking for a route with
SeqNum newer than TargSeqNum
(consider adding a maximum single hop value JWD)
I don't think this is a good idea.
(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)
Only after reboot or loss, but we allow particular deployments to use smaller
values.
(It isn’t clear what the previous sentence means as the link was already
part of the route discovery procedure if I know about it yes? JWD)
I thought that such links were blacklisted...?
(previous bullet points are a bit wordy consider using upstream and
downstream and just list, route request, route reply to confirm downstream
and route reqeust, route reply , route reply ack for upstream JWD)
I'm fine with upstream and downstream. Previously there were loud complaints
about using those terms.
If
an external process signals that a link is not bidirectional, the the
value of Neighbor.State MAY be changed to Blacklisted, e.g. notification
of a TCP timeout. (I can’t see how the above would be helpful at all JWD)
??!! I don't understand. If a node has a way to determine that a link isn't
working, that is useful information.
If the message is an RREP which answers a recently sent RREQ, or an
RREP_Ack which answers a recently sent RREP, the link to the neighbor
is bidirectional.
(The valid entry in the Multicast Route Message Table must be identified
this is too wishy washy for me to understand what is meant by recently sent
JWD!)
Should we clarify that the RREP verifies the downstream neighbor and the
RREP_Ack verifies the upstream neighbour?
If an RREP_Ack is not received within the expected time (what is the
expected time? list the entry we are checking assuming in the Multicast
Route Message Tablet? outline it. JWD)
RREP_Ack_SENT_TIMEOUT
(What does this mean? How would one determine a link to a neighbor to be
broken….suggest removing it JWD)
Does this mean to simply remove the neighbor from the blacklist? I think
that would be O.K. unless we have a reason to keep the information. But I
don't remember any reason for that.
o RREQ messages SHOULD be given priority over RERR messages for
newly invalidated routes, since the invalidated routes may not
still be in use, and if there is an attempt to use the route, a
new RERR message will be generated.
(So is this 4th or second? It’s not clear and it should be. JWD)
Well, it appears next after "Second" and "Third", but one could say "Fourth"
although it doesn't sound natural to me.
(It’s not clear to me how this priority works. Do the messages just get
dropped when tsome threshold for max number of messages is reached? Is
there some queuing method because if their isn’t I don’t see how
priority would work at all, as the choices are drop or send. This whole
section seems out of place as we have’t talked about generating messages.
I’d suggest moving or removing JWD)
This is a good point. In order to be clear, we need to say that there is a
queue of messages and then use the priority mechanism to discard low-priority
queued messages. Or, perhaps better, we can say that messages are not sent
more frequently than one message per (1 / CONTROL_TRAFFIC_LIMIT)th of a
second, and then the queue is reordered based on priority.
Messages may travel a maximum of MAX_HOPCOUNT hops.
(Messages don’t really travel though do they as they are regenerated at
each hop. JWD)
Could say "Messages may be regenerated a maximum of MAX_HOPCOUNT times.”
If packets are not queued, no notification should be
sent to the source. (What notification is sent to the source when packets
are queued? JWD)
ICMP Destination Unreachable ICMP message is mentioned later.
(This doesn’t specify with any detail what buffer methods should be used
or even some that might be appropriate. Mentioning that different buffer
methods doesn’t affect interoperability should be done JWD)
Yes, we should mention that it does not affect interoperability.
RREQ_Gen awaits reception of a Route Reply message (RREP) containing
a route toward TargAddr. (is there some table that lists routes that are
being waited on? JWD)
Only the Multicast table. For RREP_Ack, the information could be kept in the
route table for the unconfirmed route.
Section 6.7.1. The Local Route Set MAY then be updated according to
Section 6.7.2. (MAY not MUST? Why wouldn’t one update it according to
section 6.7.2? JWD)
MUST is O.K. here, I think.
(this is ambugious as there may be more than one unconfirmed LocalRoute
unless I’m missing something. JWD)
I'm not sure what's wrong here. Should we repeat "LocalRoute.Address"?
associated route request retry timers can be cancelled.
(can? not SHOULD or MUST? JWD)
I'm O.K. with this either way.
(we seem to be missing when the Route Information Base should be updated
based on the new Local Route Set. JWD)
Immediately?
(it’s not clear to me what the use case of removing the sequence number
while the route is still active will achieve. suggest removal or some small
explination JWD)
We have correctly specified the operation. Keeping sequence numbers past
their expiration time seems dangerous to me, but we could explore that as
well. Or we could initiate a unicast RREQ to get the new sequence number,
but that's just more overhead.
(how would one know if a link breaks? Assuming some external process or
notification.
JWD)
Well, layer 2 is sometimes good for that sort of information.
(it’s not clear to me how the RERR’s are identified consider rewording
to make it more clear. JWD)
I'll have to ask how it can be made more clear.
LocalRoute.State set to Unconfirmed.
(Shouldn’t they also be removed from the Route Information Base? JWD)
Unconfirmed routes cannot be used for forwarding data.
(This will only occur when a target starts sending packets to an originator
address when only part of the reverse path has been confirmed, in the middle
of a route request from originator to source? Am I correct? If so then the
route request would have been sent normally and I see no issue. JWD)
I pretty much agree, but I need to think about it some more.
(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!)
I think our Multicast Table should serve the purpose here, but we can also
have another conceptual table if that's appropriate.
There might be a problem with very short validity times on very low metric
routes in that they will be selected regardless of the time. Not a problem
but something that could cause issues. Perhaps some minimum time should be
mandated. JWD)
I am fine with a minimum time, but it would have to be in the milliseconds.
(please specify what in the message matches the configured Router Client.
JWD)
?? The Target Address matches an address of one of the router's clients or
prefixes ??
received RREP
(please specify how one determines how to check the intended recipient.
What data element in the AckReq matches what ? JWD)
I think this has to do with multicast RREP, sigh.
network or result in non-optimal paths.
(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)
Nevertheless we have to allow it because a node can change its processing
context between the time the RREQ is received and the RREP is received. Of
course malicious nodes will do this even if you tell them not to do it.
(THere needs to be some sort of table which is updated with timer
associated with this AckReq JWD)
This is related to previous comments. We can have a list, or simply delete
the unconfirmed route. In the latter case, the RREP_Ack would not match
anything...
(Shouldn’t this check come before updating? The only way the
Neighbor.State is set to Blacklisted is that its already Blacklisted and
there is no need to update the Neighbor Table. JWD)
There's something wrong here, probably a cut-and-paste error.
* If it was not expected, no actions are required.
(What are we checking! What table or timer is there to check? JWD!)
Could say, "if there is no Unconfirmed Route to be confirmed" ...
(How is this done? There is no table with recently sent RERR messages to
check. There needs to be though. JWD!)
There could be such a table.
(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 an 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.
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!)
It is described that only addresses that are actually in use need to be sent
in the regenerated RERR. I dunno, make it clearer, repeat the condition?
4. For each LocalRoute that needs to be reported:
(it’s not clear how we know which localroutes need to be reported JWD!)
Isn't this the same question?
An RREQ contains no Message TLVs.
(this ins’t mandatory, right? Just AODVv2 doesn’t define any message
TLVs for use with RREQ JWD)
This would change with the E2E authentication text.
An RREP contains no Message TLVs.
(This isn’t mandatory is it? just none are defined by AODVv2. JWD)
An RREP_Ack contains no Message TLVs.
(Mandatory or just not defined? JWD)
One could imagine a multi-purpose RREP_Ack in the future. I don't know why
this is different than the preceding.
When a LocalRoute is expunged, any precursor list associated with it
MUST also be expunged.
(I feel like this is underspecified and would be better served in a separate
document like Intermediate RREP. Is there anything wrong with leaving the
behavior required a MAY and describing that behavior in another draft? JWD)
It would be nice to understand why it is underspecified. I don't think it
belongs in a separate document.
(is MAX_SEQNUM_LIFETIME the only parameter which MUST be configured the same
across the network? JWD)
Not sure about this...
Well, that's it. I'll appreciate any comments. It's probably too long for a
single mail message, so I might break it up into parts somehow.
Regards,
Charlie P.
