[Interop-dev] [Olsr-dev] NetJSON Update for OLSRv2

[Henning Rogge]

On Tue, Dec 13, 2016 at 4:26 PM, Nemesis <(spam-protected)> wrote:
> Hi Henning,
>
> On 07/26/2016 11:17 AM, Henning Rogge wrote:
>> Hi,
>
> sorry for my late response but better late than never I suppose..

No problem... we have all some real live to do... ;)

>> I just pushed an update to the OLSRv2 NetJSON implementation, bringing
>> it to the newest spec and adding quite a bit of optional data.
>>
>> The new implementation does NOT use IP addresses as IDs anymore (it
>> prefix them with a string to make the distinction clear), which might
>> lead to trouble by NetJSON consumers that expect this.
>
> I just had a chance of looking at the result, from a usability point of
> view I have to say I don't like it, but the visualization still works.
>
> Was there a technical reason for this change?

Yes...

we had some visualization software that turned out buggy because it
assumed otherwise and compared IDs with IPs that were just the same in
the example, but not necessarily.

Using "IDs" also makes it easier to jump between the routing and the
network graph part of NetJSON, because the routing path has prefixes
as destinations, which is not exactly the same as IP addresses.

A node might have an non-routable main-IP in OLSRv2, which means even
if the IP exists, you won't find a route to the node. But in the same
moment the node might have a "locally attached network", so there is
another prefix that is pointing to the node.

Splitting IDs and data (IP addresses, prefixes, ect.) is good design
in my opinion and makes it easier to extend this scheme to new data in
the future.

Henning

>> I also added a "properties" section to a few NetJSON objects, I think
>> we should talk about updating the spec there.
>>
>> The new properties were added for the "NetworkRoutes" object, the
>> "Route" object and the "NetworkGraph" object.
>>
>> Because current NetJSON does not support a "link" between a router and
>> a normal prefix anymore, the new implementation adds "pseudo nodes"
>> for each (locally) attached network and links from their routers to
>> these nodes.
>>
>> Optional (Properties) keys for NetworkRoutes objects:
>> - router_addr: the IP address of the (destination) router responsible
>> for a routing entry
>>
>> Optional (Properties) keys for Route objects:
>> - destination_id: the router_id of the (destination) router
>> responsible for a routing entry
>> - next_router_id: the router_id of the next hop router for a routing entry
>> - next_router_addr: the IP address of the next hop router for a routing entry
>> - hops: the number of IP hops for the route (including +1 hop for
>> attached prefixes)
>> - last_router_id: the router_id for the last router before the
>> destination router
>> - last_router_addr: the IP address of the last router before the
>> destination router
>>
>> Optional (Properties) keys for NetworkGraph objects:
>> - router_addr: the IP address of the router generating the Network Graph
>>
>> Optional (Properties) keys for Node objects:
>> - router_id: the route_id of the router responsible for the node (node
>> might be an attached prefix)
>> - router_addr: the IP address of the router responsible for the node
>> (node might be an attached prefix)
>> - type: might be "local" (the local router), "lan" (locally attached
>> prefix), "node" (remote router) or "attached" (prefix attached to
>> remote router)
>>
>> Optional (Properties) keys for Link objects:
>> - in: incoming link cost (numeric)
>> - in_text: text representation of incoming link cost
>> - outgoing_tree: true if link is part of "least cost" dijkstra tree
>> - source_addr: the IP address of the source router of the link
>> - target_addr: the IP address of the destination router of the link
>> - type: might be "local" (outgoing link from local router), "lan"
>> (link from local router to attached prefix), "node" (node from or
>> between remote routers) or "attached" (link from remote router to
>> attached prefix)
>> - links: an array of "links" elements described below
>>
>> "links" elements represent the local knowledge about (multiple)
>> interfaces connecting to the direct neighbors:
>> - interface: the outgoing interface of the link on the local router
>> - source_addr: the (linklocal) source IP address of the link between
>> the two routers
>> - target_addr: the (linklocal) destination IP address of the link
>> between the two routers
>> - cost: outgoing link cost (numeric)
>> - cost_text: text representation of outgoing link cost
>> - in: incoming link cost (numeric)
>> - in_text: text representation of incoming link cost
>> - outgoing_tree: true if link is part of the "least cost" dijkstra tree.
>>
>> I have attached two example files with for NetworkGraph and NetworkRoute.
>
> There's quite a lot of information here. I haven't had the time to do a
> lot of tinkering with this data yet. That is also why I didn't reply
> back then and then forgot. I hope to be more helpful next time.
>
> Federico