Hi all,
Hi all...
So I should remove the idea of the DEFAULT_METRIC_TYPE and AODVv2 should
always include an indication of metric type?
Also, I'm now not sure how best to update this section. The text before I
tried to change it, and the text after (which I sent in the email the
other
day), are attached. If anyone has any more pointers on what to do with it,
please help.
Regards,
Vicky.
On Fri, Sep 25, 2015 at 6:14 AM, Lotte Steenbrink <
lotte.steenbrink@xxxxxxxxxxxx> wrote:
Am 25.09.2015 um 01:36 schrieb Ratliff, Stanley <sratliff@xxxxxxxxxxx>:
anyA DEFAULT_METRIC_TYPE is configured on each AODVv2 router so that
AODVv2 messages generated which are associated with that metric type do
not
means that when a metric type is not included in a message,need to explicitly include an indication of that metric type. This
DEFAULT_METRIC_TYPE
metric types, the MetricType data element MUST be included.is assumed. When sending information about routes with non-default
configuration, but if you want to include others organisations routers
Ooh not sure about this. It's ok if all your routers use the same
who
could be using a different default, the unspoken metric type will be
different, which will >>cause great problems. I believe that we should
never assume a default type. However I'm open to some text that caveats
the
use of the implied default stating that Here Be Dragons.
example of the value of doing so.For any configuration variable, it is possible to screw it up.
Nevertheless, people use configuration variables and this is a good
screw it up", I respectfully disagree with the follow-on statement
While I agree that "for any configuration variable, it is possible to
"...people use configuration variables, and this is a good example of
the
value of doing so." Actually, IMHO, it's a great example of why you
would
*not* use configuration variables. As John states, routers in an AODVv2
network *might* use different defaults, and therefore, problems will
ensue.
But those problems would *only* ensue precisely because a default was
configured, and therefore, not announced. The fix is to *always*
explicitly
include an indication of metric type. That way, there's no possibility
of
being misinterpreted. I believe that is a much better approach.
For the record, because I'm enthusiastically agreeing here: +1.
individual
Regards,
Stan
_____________________________________________________
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
or entity to whom they are addressed. If you are not the originalemail
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
in error, please delete it and immediately notify the sender.
_____________________________________________________
