Standardize node alias list about netjson HOT 14 CLOSED

I sent that link to Antonio (ordex), batman-adv contributor, he told me he's confused by the naming of the issue, because batman-adv does not have secondary ids, just one id and secondary interfaces.

He also told me that before standardazing we should see if "alias" in other routing protocols have the same meaning.

from netjson.

In OLSR there are MIDs (identifiers used on all the interfaces where the OLSR is running, in addition to the router ID). In order to get "aliases" in Babel, you need to look at all the link-local addresses of all the interfaces where Babel is listening.

And yes, router id is something else. While in OLSR, router ID is just one of the IP addresses (so it looks the same as any "alias"), for example in Babel, the router ID is not even an IP address, while aliases are IPv6 link-local addresses. So IMO "alias" is a better term and there is always only one router ID (per routing protocol).

from netjson.

Thanks @kostko 👍

Henning adds:

Hi,

maybe it would be more clear to call the list "Local Addresses" ?

Its just a list of addresses (Mac/IP) which you can use to talk to this node.

Henning

from netjson.

Yeah, that makes even more sense. So either "aliases" or "local_addresses" (is this the proposed field name?) is fine with me.

from netjson.

local_addresses sounds good because it's explicit. So according to the discussion this would make sense on OLSR, batman-adv and babel, right?

from netjson.

Yes, they are either IPv4, IPv6 (L3 routing protocols) or MAC (L2 routing protocols) addresses. So I think local_addresses is good.

from netjson.

In the "nodeinfo" format currently used by Gluon, we make a clear distinction between addresses "on top" of the batman-adv layer, and addresses on which batman-adv is running. In the latest Gluon release, we've also added some additional information about the "types" of the underlying interfaces ("wireless", "tunnel", and "other" for anything not detected as wireless or tunnel, so mostly wired connections), which we plan to use in topology visualizations.

Example of our current format:

{
  "network": {
    "mac": "XX:XX:XX:XX:XX:XX",
    "addresses": [
      "XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX",
      "fe80::XXXX:XXXX:XXXX:XXXX",
      ...
    ],  
    "mesh": {
      "bat0": {
        "interfaces": {
          "other": [
            "XX:XX:XX:XX:XX:XX",
            ...
          ],  
          "tunnel": [
            "XX:XX:XX:XX:XX:XX",
            ...
          ],  
          "wireless": [
            "XX:XX:XX:XX:XX:XX",
            ...
          ]   
        }   
      }   
    },  
    ... 
  },  
  ... 
}

mac is the address of the bat0 interface, the addresses listed under mesh/bat0/interfaces belong to the interfaces batman-adv is meshing over.

The addresses section has nothing to do with meshing at all, this is just information about the addresses the node can be contacted over.

One of the addresses listed in other, tunnel or wireless is the so-called "primary" batman-adv addresses (at least in the old batman-adv upto 2013.4, I'm not sure if something has changed about that in more recent versions). We hide that fact on purpose as the existance of a "primary" address is a detail of the inner workings of batman-adv. We don't need that information for visualization, so we don't include it at all to have as little protocol-specific information as possible in our format.

from netjson.

so anyone against local_addresses?

from netjson.

what does local addresses include? in the case of olsr, the HNA neworks will be listed as a local addresses? additional addresses on the mesh interfaces? i think that we shoud keep only the addresses listed in the routing protocol to avoid problem in the graph generation.

In the case of bmx6 or cjdns? are we going o use the hash id as identifier? can it have "aliases"?

from netjson.

@gabri94 we are proposing to rename aliases in local_addresses and keep the meaning unchanged.
But we should find a clear definition of this property.

What's a good definition in your opinion?

PS: regarding bmx6 and cjdns, it's their choice how they implement the spec, we just have to try to define what the property should be used for and why we need it.

from netjson.

Henning on the mailing list wrote: "Its just a list of addresses (Mac/IP) which you can use to talk to this node."

from netjson.

The choice are aliases and local_addresses.

After a few weeks of thoughts I prefer aliases because is short and clear enough.

from netjson.

Just as a comment, "Local Addresses" are not HNAs, because they are not prefixes.

My suggestion for HNAs would be this:
#10

from netjson.

Take a look at db8fb24 and let me know what you think.
I'll close this issue if no further comments are received.

from netjson.