<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/20/2014 01:09 PM, Henning Rogge
wrote:<br>
</div>
<blockquote
cite="mid:CAGnRvupxq1Dszz0CjwrM2ro3DJAAv7CY432jFtRRg7fzs_N2xA@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Nov 20, 2014 at 1:02 PM, Nemesis <a class="moz-txt-link-rfc2396E" href="mailto:nemesis@ninux.org"><nemesis@ninux.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I got some feedback from Antonio Quartulli (batman-adv) to see how that
would fit for batman-adv.
He told me that "source" doesn't apply for batman-adv and should be omitted
if "type" is "batman-adv".
</pre>
</blockquote>
<pre wrap="">
It would be omitted in ALL currently existing protocols... but
source-specific routing will play an important role in multi-gateway
IPv6 scenarios in the future, so we should have the field there.
</pre>
</blockquote>
<br>
Ok.<br>
<br>
<blockquote
cite="mid:CAGnRvupxq1Dszz0CjwrM2ro3DJAAv7CY432jFtRRg7fzs_N2xA@mail.gmail.com"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">We also reasoned about "cost" and "cost_type". The word "cost" implies that
is better to have a lower cost, while some algorithms might do it
differently.
So peraphs using "metric" and "metric_name" would be more generic.
</pre>
</blockquote>
<pre wrap="">
I think that is a really bad choice... we need a well-defined order on
the cost-field, otherwise external software cannot interpret this
reasonable. What use is the cost-value if you don't know which one is
better?
So I see two ways to allow metrics to go the other way around...
first would be to add a boolean field that tells you if higher is good
or bad. It makes comparing two cost/metric values more complex, but it
might make both sides happy.
second would be to allow negative numbers and flip "high is good" (or
"low is good" one) to the negative side.
</pre>
</blockquote>
<br>
Let's see... I would not want to get stuck so early.<br>
<br>
Maybe we can keep it simple and delay the having more metrics mixed
for a later moment.<br>
<br>
Can we say: this JSON should be able to represent a network topology
as seen by a routing protocol deamon configured to see only one
routing table and one metric?<br>
<br>
From the point of view of a webapp/server side app, it would be
great to have this, even if with such a limit, initially.<br>
<br>
I would like to get the simplest lowest common denominator to start
with, then we can discuss more in detail at the first occasion we
all meet in person on how to improve it, if we need it has to be
improved.<br>
<br>
Something simple like:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
"routes": [<br>
{<br>
"destination": "<id>",<br>
"source": "<id>",<br>
"next" : "<id>",<br>
"device": "<device>",<br>
"metric": "<metric value>"<br>
}<br>
]<br>
<br>
<br>
What do you think?<br>
<br>
Federico<br>
</body>
</html>