[Interop-dev] NetJSON: clarify what an ID is

Nemesis (spam-protected)
Wed Aug 12 12:05:12 CEST 2015 

Hey Juliusz,

thank you for your feedback, I really appreciate!

I took the time to analyze your inputs, I'll reply to both emails in a
single email, hoping to make it easier for others to follow the thread.

On 08/11/2015 07:17 PM, Juliusz Chroboczek wrote:
>> * make clear what an ID is (eg: can it be also a non-address, like a
>>   hash?) 
>> * you use the concept of ID also for routes but you expect addresses,
>>   please clarify 
>> * which attributes do refer to IDs in NetworkGraph and NetworkRoutes 
> Right.
>
> I'm offline at the moment (in the plane), so I cannot consult the
> "specification" right now.  I'm writing from memory, apologies if I say
> something stupid.

The spec is here: https://github.com/interop-dev/netjson - particularly
important are the short premise sections at the beginning, *Goals* and
*Motivations*.

Now i'm working to integrate the feedback got during the battlemesh in a
separate branch, you all can see the changes by looking at this pull
request:

https://github.com/interop-dev/netjson/pull/20/commits

> The current description of NetJSON is very succint

Which of the NetJSON types are you referring to? One or two in
particular? All of them?

We currently have:

  * NetworkRoutes: routing information
  * NetworkGraph: topology information
  * NetworkCollection: a list (array) of any other NetJSON type
  * DeviceConfiguration: configuration of a device, probably not
    relevant to this discussion
  * DeviceMonitoring: monitoring data of a device, probably not relevant
    to this discussion

> so I'm not sure I understand it fully, but I think that it's not general enough.  In
> particular, it will require some extensions in order to be able to fully
> represent the structures used by Babel.

We should definitely tweak NetJSON to harmonize the features that are
common to several routing protocols, while allowing each protocol to
extend and customize the JSON structures to provide additional
information that are only relevant to itself.

The spec allows extension and customization of NetworkGraph with the
properties object, which should be used mainly to store additional
attributes for visualization purposes, eg:

 1. https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L16-L18
 2. https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L33-L36

The spec also allows to add any key/value member to any NetJSON type,
GeoJSON also does this and it played out pretty nicely.

> Babel carefully distinguishes between neighbouring interfaces, which are
> identified by a link-local IP, and routers, which are identified by
> a Router-ID, a 64-bit arbitrary identifier.  There is no way to correlate
> a link-local IP with the Router-ID of the router it belongs to: a router
> may have multiple interfaces, and hence multiple link-local addresses, and
> a router may have no Router-ID at all (if it doesn't originate routes).
>
> You may want to have a look at Sections 3.2.3 and 3.2.5 of RFC 6126.
> Babel has two tables of interest to NetJSON:
>
>   (1) a neighbour table, indexed by pairs (interface, link-local IP), and
>       which contains things such as link cost;
>   (2) a route table, indexed by triples (prefix, plen, neighbour), where
>       a neighbour is an entry in the neighbour table above.

Ok, I read this section: https://tools.ietf.org/html/rfc6126#section-3.2

> Now the route table contains routes, which contain a lot of information
> that is useful to visualisation tools.  Namely:
>
>   - the link-local IP of the neighbour through which the route goes;
>   - whether the route is selected or a redundant route;
>   - the router-id of the router that originated the route;
>   - the metric advertised by the next-hop neighbour;
>   - the metric that we computed for this route.
>
> I can see at least the following issues with NetJSON from a Babel point of
> view:
>
>   - it doesn't clearly distinguish between link-local addresses and
>     router-ids;

On the after-battlemesh branch we now have:

router_id: arbitrary string that identifies the router on which the
protocol is running (eg: ip, mac, hash)

How does this definition sound? Do you think it can be improved?

NetworkGraph has a local_address attribute, eg:
https://github.com/interop-dev/netjson/blob/after-battlemesh/examples/network-graph.json#L12-L15

Its definition is: "local_addresses: array of strings representing
additional addresses (mac/ip) which can be used to communicate with the
node"

Is it relevant to the your point?

>   - it doesn't encode the difference between selected and redundant
>     routes;

You mean something like:

"a boolean flag indicating whether this route is selected, i.e., whether
it is currently being used for forwarding and is being advertised."

which is what is present in the Babel RFC at section 3.2.5 ?

I would have no problem to add such an attribute if it's relevant also
to other protocols. Otherwise it could be a Babel specific attribute,
not present in the spec, but still allowed to be there as explained before.

Regarding this point, feedback from other routing protocol developers is
particularly important (Henning, Axel, Antonio ar all in CC).

>   - it doesn't allow encoding both metrics.

Correct, we currently allow one metric per object, although is possible
to have multiple NetworkGraph and/or NetworkRoutes objects listed in a
NetworkCollection array, one for each metric. But I'm open for suggestions.

> Note that selected/redundant can alternatively be encoded by having two
> tables, one table of selected routes and one of redundant routes.  The
> advantage of doing that is that client software that only needs the
> selected routes only needs to parse the one table.

So peraphs this could be *also* solved by having two NetworkRoutes in a
NetworkCollection, eg:

{
    "type": "NetworkCollection",
    "collection": [
        {
            "type": "NetworkRoutes",
            "protocol": "babeld",
            "version": "1.6.2",
            "revision": "fcc62422414c61e6ca744a89941888d905c980c0",
            "metric": "hop-count",
            "router_id": "<babel-router-id>",
            "topology_id": "selected",
            "routes": [... list of selected routes here ...]
        }
        {
            "type": "NetworkRoutes",
            "protocol": "babeld",
            "version": "1.6.2",
            "revision": "fcc62422414c61e6ca744a89941888d905c980c0",
            "metric": "hop-count",
            "router_id": "<babel-router-id>",
            "topology_id": "redundant",
            "routes": [... list of redundant routes here ...]
        }
    ]
}


On 08/11/2015 07:20 PM, Juliusz Chroboczek wrote:
>> an ID is the way a router/node is identified in "NetworkRoutes" and
>> "NetworkGraph", it can be any string.
> Should it be a printable string, or a binary blob?  Babel's Router-IDs are
> 64-bit binary blobs, they are printed out as 12:ab:34:cd:56:ef.

Considering the JSON RFC http://rfc7159.net/rfc7159#rfc.section.3
describes a JSON value as:

"A JSON value MUST be an object, array, number, or string, or one of the
following three literal names: false null true The literal names MUST be
lowercase. No other literal names are allowed."
(when it says object it means a data structure that in other programming
languages is called "associative array" in C-like languages,
"dictionary" in python or "hash" in ruby).

Considering also the current router_id definition (after-battlemesh
branch) is:

"router_id: arbitrary string that identifies the router on which the
protocol is running (eg: ip, mac, hash)"

It makes sense to have a strings like "12:ab:34:cd:56:ef". What do you
think?

>
>> Probably routes in NetworkRoutes should expect addresses only and avoid
>> confusion with router IDs,
> Babel uses a next-hop address and an originating Router-ID.

Can the "next" attribute be an address while providing an addtional
"next_id" attribute with the originating Router-ID as proposed by
henning here? https://github.com/interop-dev/netjson/issues/9

>> In NetworkGraph instead, source and target should probably allow the usage
>> of router IDs.
> What happens if a neighbouring router has multiple interfaces?

In NetworkGraph every router (called node) can list the interfaces in
"local_addresses".

Would Babeld use local addresses or router IDs in the attributes
"source" and "target" of NetworkGraph?
Eg:
https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L30-L31

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

More information about the Interop-dev mailing list