[aodvv2-discuss] Re: Metrics (removing references to alternate metric types)
- From: "Lotte Steenbrink" <lsteen@xxxxxxxxxxxxxxxxxx>
- To: aodvv2-discuss@xxxxxxxxxxxxx
- Date: Wed, 30 Sep 2015 09:05:29 +0200
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.
Are you referring to the way OLSR represents Metrics, i.e. no matter the
metric type, it has to be mapped to a certain range of values, with the
one end of the spectrum meaning 'good' and the other end meaning 'bad'?
I'd be quite happy to adopt that, but I was under the impression that you
weren't...
- 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.
Wouldn't that defy the propose of having a default mechanism in the first
place?
- 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.
I have been told off many many times by Henning for omitting the Metric
Type TLV for DEFAULT_METRIC_TYPE. I can't imagine those complaints haven't
been raised on the MANET ML at some point, but even if they weren't I did
raise them on here (and in conference calls) on behalf of Henning.
Regards,
Lotte
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.
> _____________________________________________________
Other related posts:
