Op 1 jul 2010, om 15:25 heeft Dearlove, Christopher (UK) het volgende
> The current proposal is in the middle of the range
> logarithmically, rather than arithmetically (I would
> prefer a=0,b=15 to a=0, b=14). I can (otherwise we
> wouldn't have proposed it) see some logic to that.
> There is another value worth considering, and that
> is the maximum value. This has the potential advantage
> of clarity over that there are two different default
> - The "don't need to signal a metric thus saving
> octets" value, and
> - The "I haven't been able to work out what a good metric
> valus is yet, so let's use this" value.
> The latter should almost certainly be the maximum value.
This depends on the configuration.
The default for 10/100/1000/10000 Ethernet, where
rate is not known, should not be the max value, I think.
In general, we are in a discussion on guidelines, on what
cost value to use for what class / state of a link.
I think it is helpful to have an informational document,
with examples of (at a minimum) 802.3 and 802.11.
> The former really only has two purposes
> - If there is an often used value.
> - For hop count.
> Note that for pure hop count it is irrelevant what the default
> value is. If you are going to have cases where e.g you signal
> double hops then maximum is the worst value - and the best
> value is probably the minimum value (excluding zero, if zero
> is included). And that is another candidate.
> Incidentally inclusion of zero makes a change to OLSRv2.
> It means that you MUST pick the fewest hop route among those
> with the same metric. Without it, that becomes a SHOULD,
> or even a MAY.
As far as I understand, nobody asked for zero for OLSR.
The idea was having a generic coding scheme, and some
protocols do require a zero value (Henning says so ...).
The OLSRv2-metrics document could specify that zero MUST NOT
Same could be specified for a max value = DoNotUse. This
leaves 254 codepoints for OLSRv2.
manet mailing list