[Interop-dev] make metric a optional property of NetworkRoutes, NetworkGraph, and each Route object

[Henning Rogge]

On Fri, Mar 4, 2016 at 4:23 AM, Axel Neumann <(spam-protected)> wrote:
> On 03.03.2016 20:01, Henning Rogge wrote:
>> On Wed, Mar 2, 2016 at 7:42 AM, Axel Neumann <(spam-protected)> wrote:
>>> Hi all,
>>>
>>> I noted that currently the metric elements are required properties of
>>> NetworkRoutes and NetworkGraph objects.
>>
>> Yes.
>>
>>> With bmx6 (also old bmxd and bmx7) the metric to be used for
>>> establishing routes towards a destination is individually defined by
>>> each destination node.
>>
>> a netjson output should be the local view of the node, so I think this
>> should still work for bmx7... does it?
>
> No! Even the local view of a single node is about many routes to
> different destinations and each destination can dictate the metric
> function to be used (e.g. hopcount, etc,..) and some of its parameters.
> I understand the NetworkRoutes object can be used to represent these
> with one Route object per local route.

Still, the metrics the user configured should make sense compared with
each other... otherwise things like the gateway selection will be
quite a bit "random".

>> As a Distance-Vector protocol you most likely don't have a full
>> NetworkGraph anyways.
>
> Right. But a local route (next-hop routing entry and corresponding
> netjson Route object with destination, next, cost, and optimal source
> address) can not represent the full NetworkGraph anyway.

That is right...

> I understand that NetworkGraph objects can be used to represent local
> topologies. Even with distance-vector protocols :-)
> And then some kind of collector can fetch all these NetworkGraph objects
> from all nodes and aggregate them into a NetworkCollection object. Then
> you have a full NetworkGraph.

Yes, data aggregation can give you more data... or conflicting data
(local view is not always the same as the one of the rest of the
mesh).

>>> I think also with olsrv2 multi-topology routing this might become
>>> relevant as different metrics might then be used for different
>>> destination addresses.
>>
>> Olsrd2 just outputs multiple NetworkGraph/NetworkRoute blocks with
>> different metric/topology-id.
>>
>
> Ok
>
>>> I therefore suggest to make the metric property of each route object
>>> optional and add an optional metric property to the NetworkRoutes and
>>> NetwokGraph objects.
>>
>> I don't think this is a good idea. This makes the whole graph
>> practically useless for determining which node is close and which is
>> not.
>
> IMO, to get a neutral and global view of the topology NetworkGraph and
> NetworkCollection objects should be used.
> To represent the cost of an end-to-end route the decision of those
> controlling the metric function should be respected.
>
> Or let me ask the other way around: How to represent a BMX route to a
> destination that (for some reason) dictated to be optimized for
> hop-count? Assume that most other routes are ETX optimized.

How many metrics do you see to be used on a typical node?

If its a reasonable amount, you could easily put each of the metrics
into its own NetworkGraph/-Route object, similar to what I am doing
with multiple Topologies.

Henning