[Interop-dev] Alias list in NetJSON

[Nemesis]

On 06/01/2015 06:11 PM, Matthias Schiffer wrote:
> On 06/01/2015 11:37 AM, Nemesis wrote:
>> > On 06/01/2015 03:47 AM, Gabriel wrote:
>>> >> On 12/05/2015 15:40, Henning Rogge wrote:
>>>>> >>>> On Tue, May 12, 2015 at 3:38 PM, Nemesis <(spam-protected)> wrote:
>>>>>>> >>>>>> We noticed different routing protocols keep a list of aliases.
>>>>>>> >>>>>>
>>>>>>> >>>>>> It seems olsr jsoninfo and txtinfo use a list called "aliases" (jsoninfo) or
>>>>>>> >>>>>> "MID" (txtinfo), while batman-adv for each node has a "primary" attribute
>>>>>>> >>>>>> which is a string and a "secondary" attribute which is a list of strings.
>>>>> >>>>
>>>>> >>>> MID is the list of interface addresses. So you could consider them
>>>>> >>>> "secondary" compared to the "primary" originator address.
>>>>> >>>>
>>>>> >>>> Henning
>>>>> >>>>
>>> >> I've opened an issue on github with a proposal, please comment it.
>>> >>
>>> >> https://github.com/interop-dev/netjson/issues/15
>> > 
>> > Matthias, could that addition help out with the use case of the local
>> > topology we were discussing in a previous mail?
>> > 
>> > If each node advertised the secondary mac/ip address would it be
>> > possible to resolve the issue of the node seeing different mac addresses
>> > of the same node?
>> > 
>> > Federico
>> > 
> Well, as our "neighbours" format already contains a list of all local
> MAC addresses that is meshed over (a node in [1] is organized as a map
> "batadv"/local MAC/"neighbours"/remote MAC in the batman-adv case), we
> already have this information - you just need the local topology of two
> neighbouring nodes to see which addresses belong to the same node.
>
> In our "nodeinfo" format we include some additional information about
> these addresses (see my comment on the Github issue). I guess this could
> be easily reorganized (the neighbour list might as well be part of the
> "monitoring" format), but I think all of this information is useful for
> visualization. For example, we display VPN tunnels in a less obtrusive
> way than WLAN links to keep the graph as clear as possible.

Hey matthias,

let's recap, i'm getting lost:

  * you also have a list of local addresses
  * this information is not enough to satisfy the need of a local
    topology as we were discussing in the other thread

Is this correct?

One direct question: what's your view on Gabriel's proposal of
standardizing the "local_addresses"?
Do you see any issue with it?
Do you consider it useful to have a standard way to represent this list?

Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150610/296d77de/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150610/296d77de/attachment.sig>