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

[Juliusz Chroboczek]

> * 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 current description of NetJSON is very succint, 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.

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.

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;
  - it doesn't encode the difference between selected and redundant
    routes;
  - it doesn't allow encoding both metrics.

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.

-- Juliusz