<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hey Henning,<br>
<br>
I'll put all the answers in one email to ease reading to who's
following the discussion.<br>
<br>
I am adding Simon in CC hoping he will also provide some feedback
(feel free to forward to anyone else that might be interested).<br>
<br>
Two premises:<br>
<br>
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.<br>
<br>
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.<br>
<br>
<b>NetworkGraph</b><br>
I believe the motivation of the <i>NetworkGraph</i> is that we
need a common way to describe one or more network topologies.<br>
<br>
The goal in my opinions are:<br>
<ul>
<li><b>visualization:</b> develop awesome visualization tools
that work with any routing protocol.</li>
<li><b>monitor changes in topology</b>: 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</li>
</ul>
<p>any other idea/need?</p>
<b>NetworkRoutes</b><br>
For <i>NetworkRoutes</i>, what kind of tools can we achieve with
it? What is pushing us to define it?<br>
I would say that having a standard structure is a good idea, we
can also reuse this structure in <i>DeviceConfiguration</i> to
describe static routes (as we are already doing).<br>
<br>
any other idea?<br>
<br>
<div class="moz-cite-prefix">On 05/28/2015 11:19 AM, Henning Rogge
wrote:</div>
[...]<br>
<blockquote
cite="mid:CAGnRvuo1=JxPD1ULgZFtqvMWecKqUuWu-vPh+pSfgpuNH9Xjdg@mail.gmail.com"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<br>
I remember you mentioned this issue a while ago, now is the right
time to think about it and try to get it right.<br>
<br>
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:<br>
<a class="moz-txt-link-freetext" href="https://github.com/jsongraph/json-graph-specification/blob/master/examples/car_graphs.json">https://github.com/jsongraph/json-graph-specification/blob/master/examples/car_graphs.json</a><br>
<br>
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).<br>
<br>
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.<br>
<br>
I will explain this further with a pull request on the github
repository.<br>
<br>
On 05/28/2015 03:08 PM, Henning Rogge wrote:<br>
</div>
<blockquote
cite="mid:CAGnRvurX-CRvwsaZ8ShXRHKeWBUKUw05hvkuWtF0pDjdZZohUA@mail.gmail.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
First of all, thank you very much for doing this! This will surely
speed up adoption once we are ready.<br>
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.<br>
Everyone ok with this?<br>
<br>
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:
<a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson">https://github.com/interop-dev/netjson</a><br>
I think netjson is an acceptable name, as geojson is an acceptable
name to describe simple geographic data.<br>
<br>
What do you think?<br>
<br>
<blockquote
cite="mid:CAGnRvurX-CRvwsaZ8ShXRHKeWBUKUw05hvkuWtF0pDjdZZohUA@mail.gmail.com"
type="cite">
<pre wrap="">I have attached both "routes" and "graph" output of my plugin, that
should make it easier to explain the changes.
</pre>
</blockquote>
<br>
Just checked them out.<br>
<br>
Curiosity: is ff_dat_metric an olsr2 metric?<br>
<br>
Pay attention because in the graph.json file there is "type":
"NetworkRoutes" but according to the spec it should be:<br>
"type": "NetworkGraph"<br>
<br>
Although we should resolve this ambiguity (having two similar
objects).<br>
<br>
<blockquote
cite="mid:CAGnRvurX-CRvwsaZ8ShXRHKeWBUKUw05hvkuWtF0pDjdZZohUA@mail.gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
Let's see if I get it:<br>
<br>
for a node with an external prefix we mean a connection with another
network? Any real world scenario example to help me understand?<br>
<br>
<blockquote
cite="mid:CAGnRvurX-CRvwsaZ8ShXRHKeWBUKUw05hvkuWtF0pDjdZZohUA@mail.gmail.com"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
If these are still links perhaps it would be better to keep
consistency in order to avoid complicating the implementations.<br>
<br>
I suppose the list of endpoints could be optional?<br>
<br>
<blockquote
cite="mid:CAGnRvurX-CRvwsaZ8ShXRHKeWBUKUw05hvkuWtF0pDjdZZohUA@mail.gmail.com"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<br>
You suggest this to be as standard attribute?<br>
<br>
If yes, you suggest it to be mandatory or optional?<br>
<br>
For consistency it should be "next_id". <br>
<br>
I cannot be very helpful in this case, I hope Simon can give us some
insight.<br>
<br>
<div class="moz-cite-prefix">On 05/28/2015 04:23 PM, Henning Rogge
wrote:<br>
</div>
<blockquote
cite="mid:CAGnRvuo=J78JY2fV4Nn_oCj=Uca6yYn-aD55NaWZjWZ1MXrW3Q@mail.gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
We should keep track of this somehow, I'll be opening some issues on
github.<br>
<br>
<blockquote
cite="mid:CAGnRvuo=J78JY2fV4Nn_oCj=Uca6yYn-aD55NaWZjWZ1MXrW3Q@mail.gmail.com"
type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<br>
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 <i>NetworkGraph</i> 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.<br>
<br>
Wow this was long. Sorry for that, but it might be the only way to
do this.<br>
<br>
Federico<br>
</body>
</html>