[Interop-dev] Network Topology JSON [was: OLSRd2 JSON APIs]

[Nemesis]

On 11/20/2014 01:09 PM, Henning Rogge wrote:
> On Thu, Nov 20, 2014 at 1:02 PM, Nemesis <(spam-protected)> wrote:
>> 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".
> 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.

Ok.

>
>> 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.
> 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.
>

Let's see... I would not want to get stuck so early.

Maybe we can keep it simple and delay the having more metrics mixed for
a later moment.

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?

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.

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.

Something simple like:

"routes": [
        {
            "destination": "<id>",
            "source": "<id>",
            "next" : "<id>",
            "device": "<device>",
            "metric": "<metric value>"
        }
    ]


What do you think?

Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20141120/41298947/attachment.html>