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

[Nemesis]

Hi Axel,

On 03/04/2016 04:23 AM, Axel Neumann 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,

thank you for joining.

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

Let me understand:

  * can a packet start being routed with hopcount metric and then in the
    middle of its path take a different route because a node wants to
    use a different metric?

  * how many different metrics are available in bmx7?

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

Yes correct. I have already started working on this idea, a few days ago
I just wrote a blog post about it in which I also mentioned the
possibility of a generic collector for distance vector routing protocols:

http://nemesisdesign.net/blog/coding/network-topology-visualizer-django-netjsongraph/
(see "RECEIVE Strategy" and "Next steps" to understand what I'm talking
about)

This type of implementation is key to understanding the actual
limitations of the specification and to understand the priorities that
need to be addressed.

If you could add a way to retrieve the local NetworkGraph from bmx7, I
could already start testing the whole idea and share my findings here.

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

I understand your concern.

netjson allows to define custom properties, Henning is using a few ones
to add the "incoming" routing metric in olsrd2, for example; another
possibility is to output different /NetworkGraph/ objects for each
metric wrapped in a /NetworkCollection/;

But I think it would be better to take a step back and ask ourselves:
*"why are we are doing this?"*

The first thing we must do is to understand why we need standard
attributes like "cost", and agree on some common use cases.

The spec on this point doesn't currently help very much (so I'll need to
improve it):

    *cost:* value of the routing metric indicating the outgoing cost to
    reach the destination; lower cost is better, it MAY be omitted when
    representing static routes; Infinity and NaN are not allowed in
    accordance with the JSON RFC [RFC7159]

The main goal of having a standard cost attribute in /NetworkGraph/ was
to make it possible to determine in a standard way the quality of links
in a network.
For example: with a standard cost we could show different colors
depending on the range of the cost,
eg: "very good" could be blue, "ok" could be "green", "problematic"
could be orange and "poor" red.

In an ideal world, *I would love to have a standard cost attribute* that
would mean the same thing (or at least very close) by most protocols and
at the same time *I would also like to have a standard way to collect
and process different type of metrics* used by each protocol.

What do you think? Too utopic or achievable?

Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20160306/f802d816/attachment.html>