Subject: [manet] Request for feedback

From: "L. Aaron Kaplan" <[email-masked]>
Date: Thu, 10 Sep 2015 15:55:32 +0200

Hi MANET WG,

We would like to draw your attention to an upcoming new document called "netJSON" and ask for your feedback.

TL;DR:  go to http://netjson.org

Background: Henning and me are both in an EU FP7 project (called CONFINE). This gives us some financial means to focus on some projects. One of these projects is what I usually call a "common node DB". The idea being that every (community) wireless (mesh) network loves to invent its own registry (LIR) database. There nodes and different devices and their ownership are documented . Also on how to reach the other owner. In essence, it's a necessity for us to have such a thing for maintaining IP address assignments.
Often these node DBs don't end with IP address assignment functionalities: they often include interesting network link planning features, line of sight calculations, firmware config generation tools and of course a lot of monitoring tools.

Right now the situation is that every (community) network loves to invent its own node DB. So there is no standard. Hence we came together and started to define a **simple** JSON based format for describing our networks. This shall not replace SNMP nor netconf. It's a simple (as opposed to *S*nmp) format definition. Very flexible, and people essentially can opt in to what parts of it they want to support.

Please note that this has a different focus than netconf. Also, it is not SNMP. We looked at those.

The focus of that format is to describe mesh networks. Wireless (containing wired links for sure) mesh networks.

We also made a first RFC-ish draft: http://netjson.org/rfc.html

The source code can be seen here: https://github.com/interop-dev/netjson
(feel free to send pull requests via github)

Ultimately, the goal will be to have interoperable mesh network descriptions and thus being able to separate the coding work amongst different (community) networks (or other players in this field).

Let us know, what you think. Thanks!
Aaron.

---

From: Henning Rogge <[email-masked]>
Date: Sun, 13 Sep 2015 15:06:07 +0200

Hi everyone...

I was involved in the discussions about NetJSON, have done a NetJSON
implementation for Olsrd2 and played a bit with it.

I think this could be very useful for the MANET group... yes, we can
do everything we can do with NetJSON with SNMP and the corresponding
mibs...

but of course it would take weeks to get something complicated right
and it would be protocol specific.

It took me a two days and a few hundred lines of Javascript (and a
javascript graph API) to just build a live monitoring webpage for
olsrd2 that updates through XMLRPC. It was fun to do.

I think we should look into NetJSON, make sure with some suggestion it
fits both reactive and proactive protocols and standardize it.

Henning Rogge

On Thu, Sep 10, 2015 at 3:55 PM, L. Aaron Kaplan <[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 14 Sep 2015 10:05:31 +0000

Hi All,

I'm a big fan of this kind of thing in principle, and I like the use of 
JSON, but I worry there is some cross-over with the work that is 
happening in the ALTO group (I have cc'd them), and some of the work in 
with RESTCONF from the NETCONF people (I'm less up to speed with what 
they are doing).

Does anyone from the ALTO group have any opinions?

Rick

---

From: "L. Aaron Kaplan" <[email-masked]>
Date: Sat, 19 Sep 2015 08:42:10 +0200

Hi MANET WG,

> fits both reactive and proactive protocols and standardize it.

Thanks for the feedback Henning,

I'd like to ask others of the WG as well to take a look at the document
and give us your ideas if you think this can be applied to the mesh networks
you are running/designing/defining?

What is missing in your opinion?

Best,
Aaron.

---

From: Nemesis <[email-masked]>
Date: Sun, 20 Sep 2015 00:44:51 +0200

Hi everyone,

let me give you a little bit of background:
the NetJSON idea came after years of struggling to develop web apps for
heterogeneous networks, I mean networks made with hardware from
different vendors, different firmwares, different routing protocols
running in different areas.

Usually wifi networking software solutions are tied to a specific
vendor, a specific routing protocol, a specific firmware.

Many developers reinvent the wheel each time, the only difference is
that they develop something for firmware Y instead of X, but the
underlying features are very similar if not exactly the same.
I see very little collaboration and no interoperability. For example: I
cannot export the high level description of a Device object from
software X and import it in software Y (and automate that).
There are no libraries or tools that follow the unix philosophy, usually
tools solve too many problems in one big giant ball of software which
over time becomes unmaintainable (I did this mistake myself, and I
watched other doing the same too many times).

This is a serious issue, because it leads developers to create silos,
huge repos of software that solve too many problems but are tied to
specific situations, meaning that if other devs have slightly different
situations they will develop another silo! So much waste of human resources.

Someone writes a firmware, then it will come an agent, then a monitoring
tool tied to that firmware, then a configuration management tool with
that firmware only in mind.
Vendors do the same: see ubiquiti's software products that work only
with their stuff.
Another scenario is the visualization of network topology: someone has
written an amazing visualization tool for batman-advanced, other tools
exist to work with OLSR1, but with an heterogeneous network you don't
want to be tied to a specific vendor, routing protocol, or firmware.
Things change rapidly, we cannot throw away years of work everytime we
switch to a new technology.

After working with standards like GeoJSON and JSON-Schema I understood
that we needed something similar, some common format to describe the
basic building blocks, so that these objects can be passed from software
A to software B, allowing software A to do what A is good for, and
delegating another task to software B.

When I started to work on NetJSON, I aimed at 3 goals:

The first goal is to encourage the creation of small libraries and tools
that solve one specific problem.

The second goal is to allow all the different tools and libraries to
interoperate: talk and understand one another. Pass objects around
between software written in different programming languages by different
people in different parts of the world.

The third goal is to increase productivity: allow developers to focus on
building apps and not having to spend a huge amount of time to define
their own custom data interchange formats. Understanding the data model
and its relationships in a certain field is very time consuming!

To achieve these goals we made sure to have a very clear definition and
separation of concerns for each NetJSON object: each object serves a
specific purpose.
I also added the JSON Schema <http://json-schema.org/> definitions for
each object, which allow very easy validation and automatic UI
generation (see this prototype of automatically generated UI:
http://netjson.org/json-editor/examples/device-configuration.html).
We made sure NetJSON is flexible enough to easily add custom properties
if needed.
I want to underline that NetJSON is a data interchange format, it's not
full featured protocol, and does not describe a RESTful API or RPC API.
It's just a way to describe data. The way this data will be transferred
it's the implementer's business. It could be through a RESTful API,
websockets, binary JSON in UDP packets, or whatever.

Now, to the bad points:

  * there are not enough real world implementations, especially for the
    DeviceConfiguration and DeviceMonitoring objects
  * probably some objects can be simplified a bit
  * we got some comments that indicated that we are focusing a lot
    (maybe too much) on wifi terminology (eg: using channel instead of
    frequency)

A short list of the current NetJSON implementation is here:
https://github.com/interop-dev/netjson#implementations

Any feedback will be appreciated.
Thank you very much for your attention.

Federico Capoano