Charlie,
I’m not sure what you mean when you say “this needs to be verified”. Verified,
as in “someone needs to go off and re-read 5444”? Or as in “some additional
testing needs to be done”? Or, “algorithmically, routing protocols on top of
5444 need to be able to check on a message-by-message basis”? I’m OK with the
first one, but “not-so-much” with the second, and I’m opposed to the third.
As to your last question – obviously, other protocols care about MTU. That’s
self-evident. But other protocols don’t run on top of 5444. A reasonable,
apples-to-apples comparison here would be BGP. I don’t recall (though I could
have missed something) BGP being worried about segmenting of control plane
messages, since it (BGP) relies on TCP to carry the traffic. The same notion
applies here – we’re relying on 5444. Not necessarily because we want to, but
because it has been mandated that we have to.
The fact that I see this (running over 5444) as a rather sucky requirement
doesn’t mitigate the fact that it’s a requirement.
Regards,
Stan
From: aodvv2-discuss-bounce@xxxxxxxxxxxxx
[mailto:aodvv2-discuss-bounce@xxxxxxxxxxxxx] On Behalf Of Charlie Perkins
Sent: Monday, November 23, 2015 12:41 PM
To: aodvv2-discuss@xxxxxxxxxxxxx
Subject: [aodvv2-discuss] Re: Draft 13c
Hello Stan,
If you are going to make assumptions about what RFC 5444 does, then I think
this needs to be verified.
Do you disagree that other protocols have been required to care about MTU?
Regards,
Charlie P.
On 11/23/2015 9:05 AM, Stan Ratliff wrote:
A couple of comments inline.
On Mon, Nov 23, 2015 at 11:56 AM, Victoria Mercieca
<vmercieca0@xxxxxxxxx<mailto: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<mailto: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<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.
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 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.
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 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.
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].
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"?
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]."
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.
I dont like this. I'm sure in the past we have been criticised for using text
like "mark the neighbor as confirmed" when the exact thing it needs to say is
"set Neighbor.State to Confirmed".
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
Neighbor.State to Blacklisted. I dont think we need to be wordier.
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!
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
may exist valid reasons in particular circumstances to ignore a
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:
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...
------------------
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.
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.
How can we? When we dont know how the information we give to RFC5444 will be
presented in its packet format?
Basically, we're in the position of relying on RFC5444 to carry the signaling
traffic. If we're going to trust 5444 to carry the traffic, we (by necessity)
MUST trust 5444 to handle segmentation/reassembly of AODVv2 control messages.
Vicky is correct - we don't know the segment size on the 5444 connection, and
by definition, we cannot know. The current text, minus the MTU restrictions, is
the correct approach, given the requirement to run over 5444.
Stan
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,
Charlie P.
Regards,
Victoria.
_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________
