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

[Juliusz Chroboczek]

> 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.

I'd say that we should put stuff in the spec if it can be defined in
a routing protocol-agnostic manner, even if it is currently used by just
one protocol.

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

I'm lost here.  Does the network graph describe relations between nodes or
between interfaces?  In other words, if A has two radios and is
a neighbour twice of one interface of B, how is that represented in the
network graph?

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

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

Yes.

> 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.

It would be relevant to any modern distance-vector protocol, Babel, EIGRP,
BGP.

>>   - 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.

There's a misunderstanding.  The "remote metric" is the metric that was
advertised by the neighbour, and from which the "metric" was computed (by
adding the link cost).  I suggest adding an optional "remote metric" field.

>             "topology_id": "selected",
[...]
>             "topology_id": "redundant",

That field is badly named -- there's just one topology.

> "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?

Agreed.

> Can the "next" attribute be an address while providing an addtional
> "next_id" attribute with the originating Router-ID as proposed by
> henning here?

Fine.

>> What happens if a neighbouring router has multiple interfaces?

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

Suppose A and B have each two interfaces, A1, A2, B1 and B2.  How do you
distinguish between

  A1 -- B1

  A2 -- B2

and

  A1 -- B1
     \/
     /\
  A2 -- B2

?

> Would Babeld use local addresses or router IDs in the attributes
> "source" and "target" of NetworkGraph?

Local addresses.

-- Juliusz