A couple of comments inline.
On Mon, Nov 23, 2015 at 11:56 AM, Victoria Mercieca <vmercieca0@xxxxxxxxx>
wrote:
Hi Charlie,
Thanks for the quick reply :o) Comments in line:
On Mon, Nov 23, 2015 at 4:28 PM, Charlie Perkins <
charles.perkins@xxxxxxxxxxxxx> wrote:
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> wrote:
Hello folks,were identified in the previous diff. However there were some small changes
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
at the same time as I changed the section order this time, so I apologise
for that.
No problem, it just means that I will make a separate set of comments
slightly later.
Plus I didn't compare draft 13c against draft 12. I fear that will beThe Changes section is not gone, it was just unnecessary for it to
pretty difficult. I miss the "Changes" section, which had been kept up
to date in previous revisions.
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.
O.K. I realize that my comment sounds like a complaint, whereas I
intended it to
be more of an explanation why my commentary should be considered
incomplete.
Multiple valid routes for the same address and prefix length but
different metric type may exist in the Local Route Set, but theI dont interpret this text in the same way. "which of these routes to
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.
install" does not mean that only one may be installed.
Yes, I see that your interpretation is reasonable. I forgot that "which"
can be plural.
AODVv2 MUST NOT store routes that cost more than
MAX_METRIC[MetricType].Of course its possible to violate - when you add incoming metric to the
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'.
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"?
Well, if MAX_METRIC were 255 for an unsigned character value, it would be
"cannot".
And, in fact, beneath Table 3 we have the following text:
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.
Following this mandate, MAX_METRIC would be 255 and *not equal to*
MAX_HOPCOUNT.
I would be happier if we did adhere to the quoted paragraph.
So MAX_METRIC[HopCount] = 255, and "AODVv2 cannot store routes that cost
more than MAX_METRIC[MetricType]."
I dont like this. I'm sure in the past we have been criticised for using
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 could say:
If such an external process signals that the link is
bidirectional, mark
the neighbor as Confirmed.
text like "mark the neighbor as confirmed" when the exact thing it needs to
say is "set Neighbor.State to Confirmed".
Neighbor.State to Blacklisted. I dont think we need to be wordier.
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".
How about:
blacklist the matching Neighbor Table entry
or even:
blacklist the matching neighbor
This is not an important point. And, the more details that are added will
certainly cause it to be even less probable that a careful reader would
take
the wrong interpretation. However, at some point I hope that we can
take some decisions in the direction of improved readability, even at the
cost that a determined misinterpreter can find misinterpretation.
Again, what specifically needs to be done to blacklist it, is to set
may exist valid reasons in particular circumstances to ignore a
If one relies on the actual definition of "SHOULD" and "MUST", thenSo we dont have to report when routes are broken? These are active
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.
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!
You are reacting against a definition of "SHOULD" that seems to be
contrary to
what is specified in RFC 2119. There, "SHOULD" means "MUST" -- unless
you have
a better way. Usually, such formulations are allowable in order to cause
diligent
implementers to improve the performance of the implementation without
causing the result to be non-conformant.
If there is no cost in interoperability, and if another design can work
better than
what is recommended for AODVv2 in particular circumstances, then RFC 2119
allows us to enable that better design by specifying "SHOULD" instead of
"MUST".
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
This doesnt look to me like it means "if you have a better way". I still
think we MUST report broken routes.
I dont see a good reason to 'ignore this particular item'. What other design
might work better? We need to
report broken routes which are in use. Otherwise routers keep using them, and
packets keep getting dropped
and no-one knows!
Bravo, Vicky. IMO, this MUST stay a MUST.
In section 7.4.2. RERR Reception:
How can we? When we dont know how the information we give to RFC5444 will
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.
Oh, I was not complaining... on the contrary! I was just wondering if
you had
something particular in mind...
------------------John made a very valid point on this topic in his review on November 4th,
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??
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.
If RFC 5444 wants to specify this behavior, my opinion of RFC 5444 will
approximately double in the positive direction. In the meantime, please
verify with them that it will work as we need.
If not, then we have to specify the proper behavior to avoid
fragmentation.
be presented in its packet format?
I don't remember that the MTU specification was an issue raised against
AODVv2. Can you tell me if it was something in one of the latter reviews?It was a specific comment from a quite thorough review by John, in his
email dated 4th November.
Regards,Regards,
Charlie P.
Victoria.
