<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hey Juliusz,<br>
<br>
thank you for your feedback, I really appreciate!<br>
<br>
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.<br>
<br>
On 08/11/2015 07:17 PM, Juliusz Chroboczek wrote:<br>
</div>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<blockquote type="cite">
<pre wrap="">* 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
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
The spec is here: <a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson">https://github.com/interop-dev/netjson</a> -
particularly important are the short premise sections at the
beginning, <b>Goals</b> and <b>Motivations</b>.<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/pull/20/commits">https://github.com/interop-dev/netjson/pull/20/commits</a><br>
<br>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap="">The current description of NetJSON is very succint</pre>
</blockquote>
<br>
Which of the NetJSON types are you referring to? One or two in
particular? All of them?<br>
<br>
We currently have:<br>
<ul>
<li>NetworkRoutes: routing information<br>
</li>
<li>NetworkGraph: topology information</li>
<li>NetworkCollection: a list (array) of any other NetJSON type<br>
</li>
<li>DeviceConfiguration: configuration of a device, probably not
relevant to this discussion<br>
</li>
<li>DeviceMonitoring: monitoring data of a device, probably not
relevant to this discussion</li>
</ul>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
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: <br>
<ol>
<li><a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L16-L18">https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L16-L18</a></li>
<li><a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L33-L36">https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L33-L36</a><br>
</li>
</ol>
The spec also allows to add any key/value member to any NetJSON
type, GeoJSON also does this and it played out pretty nicely.<br>
<br>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
Ok, I read this section:
<a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc6126#section-3.2">https://tools.ietf.org/html/rfc6126#section-3.2</a><br>
<br>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap="">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;</pre>
</blockquote>
<br>
On the after-battlemesh branch we now have:<br>
<br>
router_id: arbitrary string that identifies the router on which the
protocol is running (eg: ip, mac, hash)<br>
<br>
How does this definition sound? Do you think it can be improved?<br>
<br>
NetworkGraph has a local_address attribute, eg:
<a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/blob/after-battlemesh/examples/network-graph.json#L12-L15">https://github.com/interop-dev/netjson/blob/after-battlemesh/examples/network-graph.json#L12-L15</a><br>
<br>
Its definition is: "local_addresses: array of strings representing
additional addresses (mac/ip) which can be used to communicate with
the node"<br>
<br>
Is it relevant to the your point?<br>
<br>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap=""> - it doesn't encode the difference between selected and redundant
routes;</pre>
</blockquote>
<br>
You mean something like:<br>
<br>
"a boolean flag indicating whether this route is selected, i.e.,
whether it is currently being used for forwarding and is being
advertised."<br>
<br>
which is what is present in the Babel RFC at section 3.2.5 ?<br>
<br>
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.<br>
<br>
Regarding this point, feedback from other routing protocol
developers is particularly important (Henning, Axel, Antonio ar all
in CC).<br>
<br>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap=""> - it doesn't allow encoding both metrics.
</pre>
</blockquote>
<br>
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.<br>
<br>
<blockquote cite="mid:877fp1vj66.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
So peraphs this could be <b>also</b> solved by having two
NetworkRoutes in a NetworkCollection, eg:<br>
<br>
{<br>
"type": "NetworkCollection",<br>
"collection": [<br>
{<br>
"type": "NetworkRoutes",<br>
"protocol": "babeld",<br>
"version": "1.6.2",<br>
"revision": "fcc62422414c61e6ca744a89941888d905c980c0",<br>
"metric": "hop-count",<br>
"router_id": "<babel-router-id>",<br>
"topology_id": "selected",<br>
"routes": [... list of selected routes here ...]<br>
}<br>
{<br>
"type": "NetworkRoutes",<br>
"protocol": "babeld",<br>
"version": "1.6.2",<br>
"revision": "fcc62422414c61e6ca744a89941888d905c980c0",<br>
"metric": "hop-count",<br>
"router_id": "<babel-router-id>",<br>
"topology_id": "redundant",<br>
"routes": [... list of redundant routes here ...]<br>
}<br>
]<br>
}<br>
<br>
<br>
<div class="moz-cite-prefix">On 08/11/2015 07:20 PM, Juliusz
Chroboczek wrote:<br>
</div>
<blockquote cite="mid:87614lvj1o.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<blockquote type="cite">
<pre wrap="">an ID is the way a router/node is identified in "NetworkRoutes" and
"NetworkGraph", it can be any string.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<br>
Considering the JSON RFC <a class="moz-txt-link-freetext" href="http://rfc7159.net/rfc7159#rfc.section.3">http://rfc7159.net/rfc7159#rfc.section.3</a>
describes a JSON value as:<br>
<br>
"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."<br>
(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).<br>
<br>
Considering also the current router_id definition (after-battlemesh
branch) is:<br>
<br>
"router_id: arbitrary string that identifies the router on which the
protocol is running (eg: ip, mac, hash)"<br>
<br>
It makes sense to have a strings like "12:ab:34:cd:56:ef". What do
you think?<br>
<br>
<blockquote cite="mid:87614lvj1o.wl-jch@pps.univ-paris-diderot.fr"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">Probably routes in NetworkRoutes should expect addresses only and avoid
confusion with router IDs,
</pre>
</blockquote>
<pre wrap="">
Babel uses a next-hop address and an originating Router-ID.
</pre>
</blockquote>
<br>
Can the "next" attribute be an address while providing an addtional
"next_id" attribute with the originating Router-ID as proposed by
henning here? <a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/issues/9">https://github.com/interop-dev/netjson/issues/9</a><br>
<br>
<blockquote cite="mid:87614lvj1o.wl-jch@pps.univ-paris-diderot.fr"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">In NetworkGraph instead, source and target should probably allow the usage
of router IDs.
</pre>
</blockquote>
<pre wrap="">
What happens if a neighbouring router has multiple interfaces?
</pre>
</blockquote>
<br>
In NetworkGraph every router (called node) can list the interfaces
in "local_addresses".<br>
<br>
Would Babeld use local addresses or router IDs in the attributes
"source" and "target" of NetworkGraph?<br>
Eg:
<a class="moz-txt-link-freetext" href="https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L30-L31">https://github.com/interop-dev/netjson/blob/master/examples/network-graph.json#L30-L31</a><br>
<br>
Federico<br>
</body>
</html>