[Interop-dev] Improving NetworkGraph and NetworkRoutes [was: hello new subscribers]

[Nemesis]

Hey Henning,

I'll put all the answers in one email to ease reading to who's following
the discussion.

I am adding Simon in CC hoping he will also provide some feedback (feel
free to forward to anyone else that might be interested).

Two premises:

1. without your (henning, simon and other routing protocol devs)
precious help this might never become a reality, so I believe your input
is vital.

2. I believe we have to make more explicit which are the motivations and
goals of each object that we are defining and standardizing. Since we
are talking about NetworkGraph and NetworkRoutes let's start with these
2 first.

*NetworkGraph*
I believe the motivation of the /NetworkGraph/ is that we need a common
way to describe one or more network topologies.

The goal in my opinions are:

  * *visualization:* develop awesome visualization tools that work with
    any routing protocol.
  * *monitor changes in topology*: to develop (hopefully) one (or two in
    case some people are not happy with the first attempt) reusable
    parser implementation to update the links in the node-databases

any other idea/need?

*NetworkRoutes*
For /NetworkRoutes/, what kind of tools can we achieve with it? What is
pushing us to define it?
I would say that having a standard structure is a good idea, we can also
reuse this structure in /DeviceConfiguration/ to describe static routes
(as we are already doing).

any other idea?

On 05/28/2015 11:19 AM, Henning Rogge wrote:
[...]
> I have just started on this and noticed a small problem...
>
> olsrd2 is "multitopology capable", which means it can run multiple
> topologies at the same time.
>
> How do we resolve this for the "routes" and "graph" output? Do we need
> to add another layer which allows multiple metrics, each with
> graph/routes?

I remember you mentioned this issue a while ago, now is the right time
to think about it and try to get it right.

One of the existing initiatives that I've found solves this in a similar
way to what you proposed (in the later email), that is a list of graphs:
https://github.com/jsongraph/json-graph-specification/blob/master/examples/car_graphs.json

What I like most though, is the way GeoJSON solved this. In GeoJSON you
can have a Feature (geographic object) or a FeatureCollection (a
collection of geographic objects).

I would prefer a similar approach because that would allow us to have a
collection of topologies of different routing protocols in a single JSON
document.

I will explain this further with a pull request on the github repository.

On 05/28/2015 03:08 PM, Henning Rogge wrote:
> Okay,
>
> first implementation is finished (is available as the
> "json_for_networks" plugin in the OONF repository), but I think we
> need a few changes in our JSON definition.

First of all, thank you very much for doing this! This will surely speed
up adoption once we are ready.
The problem is exactly that we aren't ready yet, so.. I hope everyone of
the developers following this discussion is aware that as we improve the
spec and we try to do better we'll have to change the existing
implementations, like this one henning just wrote or the netdiff library.
Everyone ok with this?

Second, "json for networks" doesn't sound so good for a proposed
standard so while I was in Madrid and Berlin I talked about netjson
(which also has a registered domain netjson.org), so now I just renamed
the github repository for consistency:
https://github.com/interop-dev/netjson
I think netjson is an acceptable name, as geojson is an acceptable name
to describe simple geographic data.

What do you think?

> I have attached both "routes" and "graph" output of my plugin, that
> should make it easier to explain the changes.

Just checked them out.

Curiosity: is ff_dat_metric an olsr2 metric?

Pay attention because in the graph.json file there is  "type":
"NetworkRoutes" but according to the spec it should be:
 "type": "NetworkGraph"

Although we should resolve this ambiguity (having two similar objects).

> The major change is a new level of indirection, both for routes and
> graph objects to allow multiple topologies for both of them. This is
> relevant for dualstack support, because olsrv2 has a different
> "originator ID" for IPv4 and IPv6. It would also become very useful
> for running multiple routing metrics at the same time.
>
> The second major change is an array of "endpoints" in the graph object.
>
> Links are connections between Nodes, but Endpoints are connections of
> a (Router) Node with an external prefix.

Let's see if I get it:

for a node with an external prefix we mean a connection with another
network? Any real world scenario example to help me understand?

> Similar data than Links, I
> just renamed "target" into "prefix" to make sure you don't mix up
> Links and Endpoints. Maybe they should have the same key.

If these are still links perhaps it would be better to keep consistency
in order to avoid complicating the implementations.

I suppose the list of endpoints could be optional?

> The last change was in the Routes object... I have added a "next-id"
> field, which will contain the router_id of the next hop. This is VERY
> useful when you work with linklocal IPs, because you cannot recognize
> the next-hop router by the IP!
>
> What do you think?

You suggest this to be as standard attribute?

If yes, you suggest it to be mandatory or optional?

For consistency it should be "next_id".

I cannot be very helpful in this case, I hope Simon can give us some
insight.

On 05/28/2015 04:23 PM, Henning Rogge wrote:
> Hi,
>
> two more questions... one for "routes" and one for "graph".
>
> a) do we maybe want to add the fixed field "hops" to the routes? The
> number of intermediate stations might be interesting to judge a route
> in addition to the total cost.

Going back to the motivations and goals, if this is helpful and we need
it to develop something in the near future, I would add it, otherwise we
can leave this to be discussed a later phase, in which I hope we'll meet
again to discuss points like this.

We should keep track of this somehow, I'll be opening some issues on github.

> b) what do we do about "links" that are not used for routing? Maybe
> because they are still asymmetric or they are marked as "lost"... or
> they are just too bad?

According to the goal in the premise of this mail (assuming you agree
with that premise btw) it seems clear to me that we still want the bad
links to show up in the /NetworkGraph/ object in order to visualize them
or monitor their health, we just have to be able to understand that
they're in very bad health conditions.

Wow this was long. Sorry for that, but it might be the only way to do this.

Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150531/8714889b/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/20150531/8714889b/attachment.sig>