Neighbour link data in NetworkGraph vs new object based on NetworkGraph

[nemesifier]

It was mentioned in several discussions on the mailing list that we need an object to represent neighbour link data.

This was also referred to as "link-specific" or "interface-specific".

the 1st proposed solution is to add a new top-level member in NetworkGraph would be sufficient, we have to find a good name for this member and add it to the spec.

the other (2nd) possible solution is changing the value of the type attribute but keeping the exact same structure of NetworkGraph. This could be an acceptable solution IMHO: we keep the compatibility with NetworkGraph, we avoid adding too many attributes but at the same time we also make a clear distinction between the use case of the two objects.

In my opinion, the first thing we should try to do is to have a discussion about the terminology used by different routing protocols to refer to this type of data.

The second thing we have to do is to clearly state the goal / use case for this object, what do we need to do with it? Why did we add it?

[nemesifier]

Henning wrote:

I see THREE ways Olsrd2 could supply data for these objects...

1st, it could supply interface specific data including layer-2
information about links to direct neighbors.

2nd, it could supply interface specific data with link metrics about
its 2-hop neighborhood.

3rd, it could supply node specific data with link metrics about the
whole mesh (in this case you only get the best link between each pair
of nodes).

[nemesifier]

See also attached JSON files to this mail:
https://lists.funkfeuer.at/pipermail/interop-dev/2015-September/000573.html