Multiple Graphs/Routes

[nemesifier]

See this mail and the related follow-up: https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000405.html

Hi,

I have just started on this and noticed a small problem...

olsrd2 is "multitopology capable", which means it can run multiple
topologies at the same time.

How do we resolve this for the "routes" and "graph" output? Do we need
to add another layer which allows multiple metrics, each with
graph/routes?

Henning

See also: https://lists.funkfeuer.at/pipermail/interop-dev/2015-May/000406.html

Okay,

first implementation is finished (is available as the
"json_for_networks" plugin in the OONF repository), but I think we
need a few changes in our JSON definition.

I have attached both "routes" and "graph" output of my plugin, that
should make it easier to explain the changes.

The major change is a new level of indirection, both for routes and
graph objects to allow multiple topologies for both of them. This is
relevant for dualstack support, because olsrv2 has a different
"originator ID" for IPv4 and IPv6. It would also become very useful
for running multiple routing metrics at the same time.

Attachements:

• graph.json http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150528/e9b7ed5a/attachment.json
• routes.json http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150528/e9b7ed5a/attachment-0001.json

[nemesifier]

Henning says:

why not keep it simple and allow all four kinds of NetworkXYZ elements
within a collection? Just make it a container with multiple of the
other elements inside?

My reply:

Henning, that sounds like a good idea.

Let me impersonate the devil's advocate, why do we need NetworkCollection to allow all 4 different > objects? What can we do with it? Since we have to motivate our choice, this kind of reasoning is necessary.

A possible con would be:
If I have to develop a parser, knowing that in the collection I can find 4 different objects is a different amount of work than 2.

A possible pro wouldbe:
list the devices of a network

That's cool, but why mixing? What use case do you see?

[nemesifier]

Henning says:

I could see some kind of "node information dump" which just collects everything.

We could extend our collection with a future element without breaking
old parsers... they would just skip unknown/unused sections.