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

[Axel Neumann]

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.

> 
> 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.

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.

> 
>> 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.

/axel

> 
> Henning
>