[Interop-dev] NetJSON: clarify what an ID is

[Nemesis]

On 08/13/2015 08:19 AM, Henning Rogge wrote:
> On Wed, Aug 12, 2015 at 7:49 PM, Juliusz Chroboczek
> <(spam-protected)> wrote:
>> I'm lost here.  Does the network graph describe relations between nodes or
>> between interfaces?  In other words, if A has two radios and is
>> a neighbour twice of one interface of B, how is that represented in the
>> network graph?
> I think current interpretation is that it contains relations between nodes...
>
> We were talking about the "interface specific knowledge" (which
> olsrd(2) also has for direct neighbors) but decided to delay the
> discussion.

Correct. The current goal of NetworkGraph is visualization, second comes
monitoring of network topology.
Visualizing 2 links between 2 nodes is surely possible but currently I
have never seen this.
Moreover, if the 2 logical links share the same physical channel, 99%
users won't care.
In case of 2 nodes that have 2 different radio links (2.4 GHz and 5GHz),
that could be interesting.

> Maybe a NetworkNeighborhood Object with link/interface-specific
> information about one/two-hop neighbors would be a good idea?

It depends on the goal and motivation. What do we want to do with such
an object?

I'll ask the same to Juliusz, why do you think it's important to include
this information? What do you want to achieve with it?

We have to have to fined a good balance between

simplicity and ease of implementation at the cost of reduced detail
vs
high detail at the cost of reduced simplicity

GeoJSON has been very successful and widely adopted but it does not
allow to represent very complex situations and this was a deliberate choice.

>
>>>>   - it doesn't encode the difference between selected and redundant
>>>>     routes;
>>> which is what is present in the Babel RFC at section 3.2.5 ?
>> Yes.
> What do you think about making the "redundant" routes a second
> NetworkRouting object?

Thinking about it, having an additional attribute might be interesting.

By combining the information of NetworkGraph with the information of
NetworkRoutes (including this new proposed attribute) we could build a
visualizer that could highlight the path chosen by the protocol from
node A to node K.

>>>>   - it doesn't allow encoding both metrics.
>>> Correct, we currently allow one metric per object, although is possible
>>> to have multiple NetworkGraph and/or NetworkRoutes objects listed in a
>>> NetworkCollection array, one for each metric. But I'm open for suggestions.
>> There's a misunderstanding.  The "remote metric" is the metric that was
>> advertised by the neighbour, and from which the "metric" was computed (by
>> adding the link cost).  I suggest adding an optional "remote metric" field.
> Are you talking about the link metric that was used to compute the path metric?
>
> I think the NetworkGraph should ONLY contain link metrics... path
> metrics can be put into the NetworkRouting object.

NetworkRoutes sounds more appropriate for this to me too.

>
>>>             "topology_id": "selected",
>> [...]
>>>             "topology_id": "redundant",
>> That field is badly named -- there's just one topology.
> How would you call the different "things" that are handled by
> multi-topology routing?

Henning, could pointing to a relevant section of the OLSRv2 RFC help us
understand more this attribute?

>>>> What happens if a neighbouring router has multiple interfaces?
>>> In NetworkGraph every router (called node) can list the interfaces in
>>> "local_addresses".
>> Suppose A and B have each two interfaces, A1, A2, B1 and B2.  How do you
>> distinguish between
>>
>>   A1 -- B1
>>
>>   A2 -- B2
>>
>> and
>>
>>   A1 -- B1
>>      \/
>>      /\
>>   A2 -- B2
>>
>> ?

Thanks for the explaination, I answered above.

>>> Would Babeld use local addresses or router IDs in the attributes
>>> "source" and "target" of NetworkGraph?
>> Local addresses.

MM.. I don't understand if this is an issue or not, let's try to write a
simple example...

would the following be valid?

{
    "type": "NetworkGraph",
    "protocol": "babeld",
    "version": "1.6.2",
    "metric": "hop-count",
    "router_id": "12:ab:34:cd:56:ef",
    "nodes": [
        { "id": "10.0.0.1", "label": "RouterA" }
        { "id": "10.0.0.2", "label": "RouterB" }
    ],
    "links": [
        {
            "source": "10.0.0.1",
            "target": "10.0.0.2",
            "cost": 1.000
        }
    ]
}


Fed