Y. Richard Yang

It may make sense for some of us to take a look at NetJSON. Wendy gave a thorough response, and some of us may want to take a close look as well.


---------- Forwarded message ----------
From: Wendy Roome <w.roome@...>
Date: Mon, Sep 21, 2015 at 10:50 AM
Subject: Re: NetJSON and ALTO
To: alto@...
Cc: hrogge@..., aaron@..., "Y. Richard Yang" <yry@...>, manet@..., nemesis@...

Thanks for letting the ALTO group know about NetJSON. NetJSON is related
to the proposed ALTO extensions to describe network topology. However, I
think ALTO's needs are sufficiently different, and sufficiently simpler,
that there is no advantage using NetJSON in ALTO.

The proposed ALTO topology extensions give clients a very simple, abstract
view of the network so that clients can determine how much the paths
between endpoints overlap. E.g., suppose a client wants to do parallel
backups to two different cloud servers. If the paths to servers A & B have
many common elements, while the paths to servers A & C do not, the client
would prefer to use A & C.

ALTO could use the NetJSON NetworkGraph sub-schema to describe topology,
but that is considerably more complicated than what we have proposed. For
example, a NetworkGraph has nodes, links that connect nodes, and
descriptions of routing protocols. The front-runner for describing
topology in ALTO is to provide a list of abstract network elements
involved in the path between two endpoint clusters. The elements can be
nodes, links, or combinations of those. A NetJSON NetworkGraph is
considerably more complicated, and much closer to the physical network.

Also, ALTO clients are typically enduser applications with minimal
knowledge of network internals. They want ALTO to hide the details and
give them just what the need, and no more. So few ALTO clients would need
the rest of NetJSON, and forcing them to learn it would just make it
harder to use ALTO. Similarly, I doubt that NetJSON libraries would
simplify ALTO clients; it would just mean a client has to learn how to
turn off features the client will never use.

        - Wendy Roome

>Date: Mon, 14 Sep 2015 10:05:31 +0000
>From: Rick Taylor <rick@...>
>To: Henning Rogge <hrogge@...>, "L. Aaron Kaplan"
>       <aaron@...>
>Cc: manet IETF <manet@...>, Nemesis Capoano <nemesis@...>,
>       "alto@..." <alto@...>
>Subject: Re: [alto] [manet] Request for feedback
>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?
>On 13/09/15 14:06, Henning Rogge wrote:
>>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
>>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 <aaron@...>
>>>We would like to draw your attention to an upcoming new document called
>>>"netJSON" and ask for your feedback.
>>>TL;DR:  go to
>>>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:
>>>The source code can be seen here:
>>>(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!
>>>manet mailing list
>>manet mailing list

| Y. Richard Yang <yry@...>   |
| Professor of Computer Science       |