Hello folks,
Here are some reasons to not remove DEFAULT_METRIC_TYPE.
- Until someone publishes another metric, removing it is a penalty on
every implementation.
- It would simply be a mistake to mangle the settings on different
network devices. We don't have to protect against all such mistakes.
- The difficulty about mismatched metric types is unfortunate, but not
fatal. As proof, one can refer to the mishmash metric supported by OLSR.
- Mismanaging the default metric type is a lot different than, and much
less likely than, say, mismanaging policy knobs.
- In the unlikely event that it becomes a problem, future metric
specifications could mandate that use of their metric REQUIRES the
metric-type TLV and cannot make use of the default mechanism.
- Removing the feature costs time and space over the air, increasing
interference etc.
Disregarding all of this simply to protect against a potential
mismanagement pitfall does not make sense to me.
It's especially mysterious, given that no one has complained about it on
the mailing list.
Regards,
Charlie P.
On 9/27/2015 2:03 AM, Victoria Mercieca wrote:
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 <mailto:lotte.steenbrink@xxxxxxxxxxxx>> wrote:
Am 25.09.2015 um 01:36 schrieb Ratliff, Stanley
<sratliff@xxxxxxxxxxx <mailto:sratliff@xxxxxxxxxxx>>:
>>>> A DEFAULT_METRIC_TYPE is configured on each AODVv2 router so
that any AODVv2 messages generated which are associated with that
metric type do not
>>>> need to explicitly include an indication of that metric type.
This means that when a metric type is not included in a message,
DEFAULT_METRIC_TYPE
>>>> is assumed. When sending information about routes with
non-default metric types, the MetricType data element MUST be
included.
>>>
>>> Ooh not sure about this. It's ok if all your routers use the
same configuration, but if you want to include others
organisations routers 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.
>>>
>> For any configuration variable, it is possible to screw it up.
>>
>> Nevertheless, people use configuration variables and this is a
good example of the value of doing so.
>>
>
> While I agree that "for any configuration variable, it is
possible to screw it up", I respectfully disagree with the
follow-on statement "...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.
>
> 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
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.
> _____________________________________________________
