<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Axel,<br>
<br>
On 03/04/2016 04:23 AM, Axel Neumann wrote:<br>
</div>
<blockquote cite="mid:56D8FF99.1090705@cgws.de" type="cite">
<pre wrap="">On 03.03.2016 20:01, Henning Rogge wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, Mar 2, 2016 at 7:42 AM, Axel Neumann <a class="moz-txt-link-rfc2396E" href="mailto:neumann@cgws.de"><neumann@cgws.de></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi all,</pre>
</blockquote>
</blockquote>
</blockquote>
<br>
thank you for joining.<br>
<br>
<blockquote cite="mid:56D8FF99.1090705@cgws.de" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">
I noted that currently the metric elements are required properties of
NetworkRoutes and NetworkGraph objects.
</pre>
</blockquote>
<pre wrap="">
Yes.
</pre>
<blockquote type="cite">
<pre wrap="">With bmx6 (also old bmxd and bmx7) the metric to be used for
establishing routes towards a destination is individually defined by
each destination node.
</pre>
</blockquote>
<pre wrap="">
a netjson output should be the local view of the node, so I think this
should still work for bmx7... does it?
</pre>
</blockquote>
<pre wrap="">
No! Even the local view of a single node is about many routes to
different destinations and each destination can dictate the metric
function to be used (e.g. hopcount, etc,..) and some of its parameters.
I understand the NetworkRoutes object can be used to represent these
with one Route object per local route.
</pre>
</blockquote>
<br>
Let me understand:<br>
<ul>
<li>can a packet start being routed with hopcount metric and then
in the middle of its path take a different route because a node
wants to use a different metric?<br>
<br>
</li>
<li>how many different metrics are available in bmx7?<br>
</li>
</ul>
<blockquote cite="mid:56D8FF99.1090705@cgws.de" type="cite"><br>
<blockquote type="cite">
<pre wrap="">As a Distance-Vector protocol you most likely don't have a full
NetworkGraph anyways.
</pre>
</blockquote>
<pre wrap="">
Right. But a local route (next-hop routing entry and corresponding
netjson Route object with destination, next, cost, and optimal source
address) can not represent the full NetworkGraph anyway.
I understand that NetworkGraph objects can be used to represent local
topologies. Even with distance-vector protocols :-)
And then some kind of collector can fetch all these NetworkGraph objects
from all nodes and aggregate them into a NetworkCollection object. Then
you have a full NetworkGraph.
</pre>
</blockquote>
<br>
Yes correct. I have already started working on this idea, a few days
ago I just wrote a blog post about it in which I also mentioned the
possibility of a generic collector for distance vector routing
protocols:<br>
<br>
<a class="moz-txt-link-freetext" href="http://nemesisdesign.net/blog/coding/network-topology-visualizer-django-netjsongraph/">http://nemesisdesign.net/blog/coding/network-topology-visualizer-django-netjsongraph/</a><br>
(see "RECEIVE Strategy" and "Next steps" to understand what I'm
talking about)<br>
<br>
This type of implementation is key to understanding the actual
limitations of the specification and to understand the priorities
that need to be addressed.<br>
<br>
If you could add a way to retrieve the local NetworkGraph from bmx7,
I could already start testing the whole idea and share my findings
here.<br>
<br>
<blockquote cite="mid:56D8FF99.1090705@cgws.de" type="cite"><br>
<blockquote type="cite"><br>
<blockquote type="cite">
<pre wrap="">I think also with olsrv2 multi-topology routing this might become
relevant as different metrics might then be used for different
destination addresses.
</pre>
</blockquote>
<pre wrap="">
Olsrd2 just outputs multiple NetworkGraph/NetworkRoute blocks with
different metric/topology-id.
</pre>
</blockquote>
<pre wrap="">
Ok
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I therefore suggest to make the metric property of each route object
optional and add an optional metric property to the NetworkRoutes and
NetwokGraph objects.
</pre>
</blockquote>
<pre wrap="">
I don't think this is a good idea. This makes the whole graph
practically useless for determining which node is close and which is
not.
</pre>
</blockquote>
<pre wrap="">
IMO, to get a neutral and global view of the topology NetworkGraph and
NetworkCollection objects should be used.
To represent the cost of an end-to-end route the decision of those
controlling the metric function should be respected.
Or let me ask the other way around: How to represent a BMX route to a
destination that (for some reason) dictated to be optimized for
hop-count? Assume that most other routes are ETX optimized.
/axel
</pre>
</blockquote>
<br>
I understand your concern.<br>
<br>
netjson allows to define custom properties, Henning is using a few
ones to add the "incoming" routing metric in olsrd2, for example;
another possibility is to output different <i>NetworkGraph</i>
objects for each metric wrapped in a <i>NetworkCollection</i>;<br>
<br>
But I think it would be better to take a step back and ask
ourselves: <b>"why are we are doing this?"</b><br>
<br>
The first thing we must do is to understand why we need standard
attributes like "cost", and agree on some common use cases. <br>
<br>
The spec on this point doesn't currently help very much (so I'll
need to improve it):<br>
<blockquote><b>cost:</b> value of the routing metric indicating the
outgoing cost to reach the destination; lower cost is better, it
MAY be omitted when representing static routes; Infinity and NaN
are not allowed in accordance with the JSON RFC [RFC7159]<br>
</blockquote>
The main goal of having a standard cost attribute in <i>NetworkGraph</i>
was to make it possible to determine in a standard way the quality
of links in a network.<br>
For example: with a standard cost we could show different colors
depending on the range of the cost,<br>
eg: "very good" could be blue, "ok" could be "green", "problematic"
could be orange and "poor" red.<br>
<br>
In an ideal world, <b>I would love to have a standard cost
attribute</b> that would mean the same thing (or at least very
close) by most protocols and at the same time <b>I would also like
to have a standard way to collect and process different type of
metrics</b> used by each protocol.<br>
<br>
What do you think? Too utopic or achievable?<br>
<br>
Federico<br>
</body>
</html>