On 28.6.2015 21.22, Juliusz Chroboczek wrote:
Markus, Steven,
Unless I'm mistaken, there's an issue with DNCP and monitoring nodes.
Consider the following topology:
A --- M --- B
I would not call that node 'monitor'; instead e.g. 'forwarding' or
'bridge' node. To me, 'monitor' implies passive observation. This does
not seem to be that.
A and B are ordinary DNCP nodes, while M is a monitoring node, as
described in the second paragraph of Section 4.4. So M doesn't publish
a NODE-STATE TLV, but other than that it fully participates in the
protocol.
Due to the silly walk described in Section 4.6, A's network state
consists of just itself, and similarly B. Whenever M sends a NODE-STATE
TLV, either A's or B's Trickle timers are reset, leading to excessive
traffic.
I wonder if it is too late to change it to 'silly walk', it is much
better than the boring 'topology graph traversal' that Thomas Clausen
wanted.
I don't see a good solution to that. If you don't reset trickle when
you see inconsistency from a node that doesn't publish NODE-STATE, then
you have a bootstrapping problem (new node whose NODE-STATE is
unknown). If you forbid monitoring nodes from sending NODE-STATE, then
you break Trickle for them.
Perhaps there's no good way to allow a node to participate without
publishing NODE-STATE. Grr.
That, essentially.
However, if you want to _bridge_ stuff, you can just forward 'things
from A to B, and things from B to A' on the M node, and it should work.
You can even rate limit them to some degree and do some other things I
rather not commit in writing though :)
Cheers,
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
