Hello Vicky,
Thanks for your responses! I have some more follow-up below.
On 11/23/2015 7:35 AM, Victoria Mercieca wrote:
Hi Charlie,
Thanks for looking over the changes.
Comments in-line:
On Mon, Nov 23, 2015 at 2:02 PM, Charlie Perkins <charles.perkins@xxxxxxxxxxxxx <mailto:charles.perkins@xxxxxxxxxxxxx>> wrote:
Hello folks,
I have a few comments on draft 13c, but based only on the highlighted
sections from the Diff file. That way of commenting has
limitations that
result when whole sections of text are moved. It then becomes
difficult
to compare those sections for changes.
Which is why I chose to move the section, after I made the changes which were identified in the previous diff. However there were some small changes at the same time as I changed the section order this time, so I apologise for that.
Plus I didn't compare draft 13c against draft 12. I fear that will be
pretty difficult. I miss the "Changes" section, which had been
kept up
to date in previous revisions.
The Changes section is not gone, it was just unnecessary for it to contain changes between every version of the draft we ever released. I have omitted to keep it up-to-date in the minor updates, but I will update it correctly before releasing a version 13 to MANET.
Multiple valid routes for the same address and prefix length but
different metric type may exist in the Local Route Set, but the
decision of which of these routes to install in the Routing
Information Base to use for forwarding is outside the scope of
AODVv2.
This is written under the presumption that the RIB cannot contain
multiple routes for the same destination. However, I do not think
we should presume that. It is perfectly reasonable to have a RIB
that includes the metric type as a selector.
I dont interpret this text in the same way. "which of these routes to install" does not mean that only one may be installed.
AODVv2 MUST NOT store routes that cost more than
MAX_METRIC[MetricType].
Somehow this loses the perhaps important information that
typically MAX_METRIC would be chosen to be the maximum
value that is representable. Mandating something that is not
possible to violate is like saying the speed of light MUST NOT
exceed some constant value usually denoted as 'c'.
Of course its possible to violate - when you add incoming metric to the link cost. OK, the actual comparison is "advertised cost < MAX_METRIC - link cost", but saying "MUST NOT store routes that cost more than MAX_METRIC" is perfectly readable. Would you prefer "MUST NOT attempt to store routes that cost more than MAX_METRIC"?
MAX_METRIC[MetricType] MUST always be the maximum expressible metric
value of type MetricType. Field lengths associated with metric
values are found in Section 11.6.
If such an external process signals that the link is
bidirectional,
the value of Neighbor.State MAY be set to Confirmed.
The previous formulation was quite a bit more readable and, thus
in my opinion, better. Perhaps for the most pedantic reviewers,
we could insert a definition something like:
mark a neighbor as Blacklisted
set Neighbor.State to the value Blacklisted
and go back to more readable language.
This hasnt actually changed since version 12. Also your comment does not apply to the sentence you have quoted. What would you like the "If such an external process..." sentence to say?
It is currently very clear exactly what needs to happen. In the later sentence, it seems overkill to say "update the matching Neighbor Table entry by marking the neighbour as blacklisted, by setting Neighbor.State to the value Blacklisted".
If one relies on the actual definition of "SHOULD" and "MUST", then
I think the changes in section 6.9.2 are ill-advised.
When LocalRoute.State changes from Active to Invalid as a
result of a
broken link or a received Route Error (RERR) message, other AODVv2
routers MUST be informed by sending an RERR message containing
details of the invalidated route.
The MUST should be a SHOULD. This is because (a) interoperability is
not affected and (b) if the system designer has a better mechanism to
notify for errors, we should not penalize that design and (c) for some
systems, routes may only be used once or only upon rare occasions.
So we dont have to report when routes are broken? These are active routes, therefore they are in use, so we need to report them!!!
We dont say that we should report routes that become invalid due to timeouts, do we? I think your comment applies in that case, but I dont think we mention reporting timed out routes!
In section 7.4.2. RERR Reception:
1. Update the Neighbor Table according to Section 6.3
It's probably a good idea. Could you describe the expected improvement?
Well, doesn't it make sense to put an entry in the Neighbor Table when you receive a message from a neighboring router? Maybe we dont need it for RERR, I was trying to be consistent.
------------------
Regarding the deletion of MTU-related mandates:
This is a bad idea. Even TCP is built to respect MTU
considerations. It is
especially a bad idea to avoid mentioning MTU when specifying RERR.
If necessary, I could find quite a few examples in other RFCs
where MTU
dictates certain size restrictions.
I'm pretty sure the RFC 5444 authors don't want to be saddled with
creating multiple RERR messages when AODV makes one that is too long.
Fragmentation has its own pitfalls, well known in the Internet.
Please reconsider this. Were there complaints about it??
John made a very valid point on this topic in his review on November 4th, and we discussed it in a few further emails. How can we know when we hit the MTU since RFC5444 is creating the message, we are just giving it contents. We are giving RFC5444 "message header info" + (however many routes we are reporting) * ("address + associated TLVs"). RFC5444 is best placed to determine when to create a second message, since we dont know how RFC5444 is going to arrange our information. To create a second RERR, all it needs to do is use the same "message header info" and include a separate set of "address + associated TLVs". I dont imagine this will be too difficult.
