[Interop-dev] link-specifc / interface-specific / neighbour link data [was: RFC: add parameter link-type]

[Nemesis]

I just opened a new issue:
https://github.com/interop-dev/netjson/issues/25

I copy the text here for the joy of the archive:

-----------------------

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?

------------------------

Federico


On 09/03/2015 12:36 PM, Henning Rogge wrote:
> hi,
>
> any comments on the idea of a "link specific" (or interface specific)
> boolean flag for topologies?
>
> This would allow olsrd(2) to export its Hello-based (interface
> specific) data and its TC-based (node specific) data both with the
> same NetJSON object while still keeping a chance for a processing
> script to discover what to expect in the data.
>
> Henning
>
> On Thu, Sep 3, 2015 at 11:16 AM, Bastian Bittorf <(spam-protected)> wrote:
>> * Nemesis <(spam-protected)> [31.08.2015 09:06]:
>>> On 08/28/2015 02:04 PM, Bastian Bittorf wrote:
>>>> * Nemesis <(spam-protected)> [28.08.2015 13:49]:
>>>>>> this will not work, because one node can have different interfaces with
>>>>>> different types - how can i add that to properties?
>>>>> Link objects can have properties too!
>>>> oh - soooo easy?! thank you:
>>>> http://intercity-vpn.de/networks/giancarlo/meshrdf/netjson.html
>>>> (mixed wireless+ethernet)
>>>>
>>>> next week i will implement the subtypes. (frequency + channelwidth)
>>>
>>> Well I found out a few things to change in networkgraph to allow
>>> customizing colors more easily.
>>>
>>> For the moment try this crappy hack:
>> ok, worked again on this issue (small net, dualradio-hardware 2.4/5 GHz mixed)
>> http://intercity-vpn.de/networks/giancarlo/meshrdf/netjson.html
>> http://intercity-vpn.de/networks/giancarlo/meshrdf/map.json
>>
>> i introduced/hacked 3 new properties and modified your script:
>>
>> link.carrier (e.g. ethernet|wireless)
>> link.frequency (e.g. 5180)
>> link.chanbw (e.g. 5)
>>
>> now ethernet links have another color.
>> the next step would be:
>>
>> change colors of the wireless links according to cost.
>> show speed of a link
>> show "nexthop" (but this is difficult, because the nexthop
>> can change when e.g. using source-specific-routing)
>>
>> another thing: who feels responsible for this
>> javascript live-topology during battlemesh v6?
>> https://www.youtube.com/watch?v=MXFz6QdfgP8
>>
>> bye, bastian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150903/7a2162ae/attachment.html>