<html>

  <head>

    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <div class="moz-cite-prefix">On 06/01/2015 06:11 PM, Matthias

      Schiffer wrote:<br>

    </div>

    <blockquote cite="mid:556C8419.3000301@universe-factory.net"

      type="cite">

      <pre wrap="">On 06/01/2015 11:37 AM, Nemesis wrote:

</pre>

      <blockquote type="cite" style="color: #000000;">

        <pre wrap=""><span class="moz-txt-citetags">> </span>On 06/01/2015 03:47 AM, Gabriel wrote:

</pre>

        <blockquote type="cite" style="color: #000000;">

          <pre wrap=""><span class="moz-txt-citetags">>> </span>On 12/05/2015 15:40, Henning Rogge wrote:

</pre>

          <blockquote type="cite" style="color: #000000;">

            <blockquote type="cite" style="color: #000000;">

              <pre wrap=""><span class="moz-txt-citetags">>>>> </span>On Tue, May 12, 2015 at 3:38 PM, Nemesis <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:nemesis@ninux.org"><nemesis@ninux.org></a> wrote:

</pre>

              <blockquote type="cite" style="color: #000000;">

                <blockquote type="cite" style="color: #000000;">

<pre wrap=""><span class="moz-txt-citetags">>>>>>> We noticed different routing protocols keep a list of aliases.

<span class="moz-txt-citetags">>>>>>></span>

<span class="moz-txt-citetags">>>>>>> </span>It seems olsr jsoninfo and txtinfo use a list called "aliases" (jsoninfo) or

<span class="moz-txt-citetags">>>>>>> </span>"MID" (txtinfo), while batman-adv for each node has a "primary" attribute

<span class="moz-txt-citetags">>>>>>> which is a string and a "secondary" attribute which is a list of strings.

</pre>

                </blockquote>

              </blockquote>

              <pre wrap=""><span class="moz-txt-citetags">>>>></span>

<span class="moz-txt-citetags">>>>> </span>MID is the list of interface addresses. So you could consider them

<span class="moz-txt-citetags">>>>> "secondary" compared to the "primary" originator address.

<span class="moz-txt-citetags">>>>></span>

<span class="moz-txt-citetags">>>>> </span>Henning

<span class="moz-txt-citetags">>>>></span>

</pre>

            </blockquote>

          </blockquote>

<pre wrap=""><span class="moz-txt-citetags">>> I've opened an issue on github with a proposal, please comment it.

<span class="moz-txt-citetags">>></span>

<span class="moz-txt-citetags">>> </span><a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/issues/15">https://github.com/interop-dev/netjson/issues/15</a>

</pre>

        </blockquote>

        <pre wrap=""><span class="moz-txt-citetags">> </span>

<span class="moz-txt-citetags">> </span>Matthias, could that addition help out with the use case of the local

<span class="moz-txt-citetags">> topology we were discussing in a previous mail?

<span class="moz-txt-citetags">> </span>

<span class="moz-txt-citetags">> </span>If each node advertised the secondary mac/ip address would it be

<span class="moz-txt-citetags">> </span>possible to resolve the issue of the node seeing different mac addresses

<span class="moz-txt-citetags">> of the same node?

<span class="moz-txt-citetags">> </span>

<span class="moz-txt-citetags">> </span>Federico

<span class="moz-txt-citetags">> </span>

</pre>

      </blockquote>

      <pre wrap="">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"<i class="moz-txt-slash"><span class="moz-txt-tag">/</span>local MAC<span class="moz-txt-tag">/</span></i>"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.</pre>

    </blockquote>

    <br>

    Hey matthias,<br>

    <br>

    let's recap, i'm getting lost:<br>

    <ul>

      <li>you also have a list of local addresses</li>

      <li>this information is not enough to satisfy the need of a local

        topology as we were discussing in the other thread</li>

    </ul>

    Is this correct?<br>

    <br>

    One direct question: what's your view on Gabriel's proposal of

    standardizing the "local_addresses"?<br>

    Do you see any issue with it?<br>

    Do you consider it useful to have a standard way to represent this

    list?<br>

    <br>

    Federico<br>

  </body>

</html>